10 największych zagrożeń interfejsu OWASP API

Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

W tym dokumencie opisujemy różne metody rozwiązywania problemów z lukami w zabezpieczeniach zidentyfikowanymi przez OWASP. Dodatkowe metody udokumentowane w przypadku Apigee znajdziesz w artykule na temat najlepszych metod łagodzenia skutków pandemii OWASP w 2021 roku w Google Cloud.

Wstęp

OWASP to otwarta społeczność, która pomaga organizacjom w tworzeniu, kupowaniu i utrzymywaniu zaufanych aplikacji oraz interfejsów API. W ramach projektu zabezpieczeń interfejsu OWASP API OWASP publikuje najważniejsze zagrożenia dla aplikacji internetowych i interfejsów API typu REST oraz udostępnia zalecenia dotyczące rozwiązywania tych zagrożeń.

W tym dokumencie omówiono sposoby ochrony przed popularnymi atakami opartymi na interfejsach API. Omówione zostały przez OWASP 10 najważniejszych zagrożeń dla bezpieczeństwa interfejsów API w 2019 roku. Częstym motywem na liście najważniejszych zagrożeń na ostatniej liście jest nieprawidłowe umiejscowienie ustawień uwierzytelniania i autoryzacji, na przykład poleganie na filtrowaniu danych zwracanych przez żądanie do interfejsu API w aplikacjach klienckich przez używanie skrajnego wzorca polegania na tym, która aplikacja kliencka jest używana do egzekwowania kontroli dostępu.

W związku z rozwojem ekosystemu interfejsów API w szybkim tempie nadużycia i niewłaściwe użycie interfejsów API skutkujące wydobyciem danych przez osoby przeprowadzające ataki stają się obecnie jednym z najczęstszych wektorów ataków. Bezpieczeństwo wciąż jest priorytetem Apigee dzięki nowym funkcjom, takim jak Advanced API Ops (Zaawansowane operacje interfejsu API), które obejmują funkcje raportowania zabezpieczeń i wykrywania anomalii. Jednak prawidłowe zaprojektowanie i wdrożenie funkcji zabezpieczeń Apigee ma kluczowe znaczenie dla zmniejszenia prawdopodobieństwa udanych ataków na interfejsy API.

Aplikacje konsumenckie powinny być traktowane jako niezaufane lub „publiczne”, ponieważ nie masz kontroli nad platformą, na której działają. Zakładamy, że każda aplikacja publiczna może zostać zaatakowana i zostanie zaatakowana. Dlatego nie można jej zaufać i nie można jej zaufać przy wymuszaniu kontroli dostępu (API1, API5), filtrowania danych odpowiedzi (API6) ani bezpiecznego przechowywania obiektów tajnych klienta (API2), takich jak klucze interfejsu API czy tokeny dostępu. Podczas przyjrzenia się 10 najlepszych inicjatyw OWASP w 2019 roku przedstawiamy kilka zaleceń:

  • Określ rodzaj aplikacji klienckich, które będą korzystać z interfejsów API (SPA, urządzenia mobilne lub przeglądarki), i zaprojektuj odpowiednie wzorce uwierzytelniania, autoryzacji i zabezpieczeń.
  • Zawsze używaj przepływów OAuth „klienta publicznego” lub OpenID Connect (zdecydowanie zalecamy korzystanie z PKCE)
  • Zastanów się nad logiką biznesową swojej aplikacji, najpierw zdefiniuj specyfikację OpenAPI i zaprojektuj serwery proxy API, aby filtrować wszystkie dane odpowiedzi z backendu w Apigee. Nigdy nie polegaj na logice kodu aplikacji pobieranej po wykonaniu tej czynności.
  • Filtruj wszystkie żądania danych zawierające informacje umożliwiające identyfikację użytkownika, aby zezwalać tylko na dane z backendu, które należą do użytkownika wysyłającego prośbę.

API1:2019 Uszkodzona autoryzacja na poziomie obiektu

Opis zagrożenia

Niewystarczająca weryfikacja autoryzacji żądania dostępu do obiektu umożliwia hakerowi wykonanie nieautoryzowanej czynności przez ponowne użycie tokena dostępu. Zagrożenie jest spowodowane nieprawidłową konfiguracją weryfikacji autoryzacji. Apigee udostępnia zasady VerificationApiKey, OAuth i JSON Web Token (JWT), które chronią przed tą luką w zabezpieczeniach. Jednak tak ważne jest, aby te zasady były prawidłowo skonfigurowane, aby zapobiegać temu zagrożeniom.

Aby zapobiec temu zagrożeniu, zespoły zajmujące się tworzeniem aplikacji i bezpieczeństwem powinny ściśle ze sobą współpracować. Autoryzacja to z natury złożony temat, a skuteczna, szczegółowa autoryzacja wymaga dogłębnego zrozumienia logiki biznesowej aplikacji.

Oto 2 główne aspekty, które warto wziąć pod uwagę z perspektywy implementacji Apigee:

  • Integralność tokenów dostępu
  • Wymuszanie kontroli dostępu

Integralność tokena dostępu

Bardzo ważne jest, aby sprawdzić, czy token podany przez klienta wysyłającego żądanie nie został zmieniony. W tym celu należy użyć prawidłowego procesu OAuth lub OpenID Connect oraz odpowiedniego mechanizmu weryfikacji lub podpisywania danych logowania. Apigee obsługuje wszystkie powszechnie używane przepływy OAuth.

Zasady weryfikacji tokena dostępu Apigee obejmują:

Egzekwowanie kontroli dostępu

Po sprawdzeniu poprawności tokena dostępu należy wdrożyć zasady egzekwowania kontroli dostępu, aby móc oceniać każde przychodzące żądanie do interfejsu API pod kątem uprawnień dostępu związanych z tokenem autoryzacji.

Apigee udostępnia 2 główne mechanizmy weryfikacji i egzekwowania zasad autoryzacji:

  • Wewnętrzne: za pomocą procesów warunkowych oceniających żądania dostępu na podstawie deklaracji wyodrębnionych jako zmienne przepływu z tokena autoryzacji
  • Przekazane: użycie objaśnienia dotyczącego usługi do rozwiązania do zarządzania dostępem innej firmy

Jeśli model kontroli dostępu jest stosunkowo prosty, zalecamy podejście wewnętrzne (przedstawione na ilustracji powyżej). Jeśli na przykład deklaracje wyodrębnione z tokena dostępu mogą być używane do bezpośredniego oceny i autoryzacji żądania dotyczącego obiektu API.

Użyj zmiennych przepływu dostępnych dla zasad OAuth lub JWT, aby ocenić żądania dostępu za pomocą warunkowych instrukcji przepływu.

Metoda przekazywania (przedstawione na ilustracji powyżej) jest zalecana, gdy deklaracji wyodrębnionych z tokena dostępu nie można używać bezpośrednio do autoryzowania żądania interfejsu API do obiektu backendu lub w przypadku bardziej złożonych typów przepływów OAuth, które wymagają osobnego wywołania serwera autoryzacji w celu uzyskania tokena dostępu.

Korzystając z zasady objaśnienia dotyczącego usługi, można zażądać od usługi innej firmy decyzji dotyczącej zasady autoryzacji lub uzyskać dodatkowe informacje o zgłaszającym do agenta, aby na tej podstawie podjąć decyzję dotyczącą kontroli dostępu, stosując proces warunkowy.

API2:2019 nieprawidłowe uwierzytelnianie użytkownika,

Opis zagrożenia

Nieprawidłowo wdrożone zasady uwierzytelniania użytkowników umożliwiają hakerom podszywanie się pod wiarygodnych użytkowników przez wykorzystywanie błędów w implementacji uwierzytelniania. Oto kilka zasad uwierzytelniania, o których warto pamiętać przy wdrażaniu metod uwierzytelniania:

  • Zawsze uwierzytelniaj zarówno klienta użytkownika (aplikację), jak i użytkownika wysyłającego prośbę
  • Używaj wzorców uwierzytelniania delegowanego i autoryzacji oraz unikaj przekazywania haseł bezpośrednio w żądaniu do interfejsu API
  • Zawsze weryfikuj podpis danych logowania i upewnij się, że wszystkie używane dane logowania mają określony czas ważności
  • Zapobiegaj atakom brute-force, ustalając limity i korzystając z Apigee Sense do wykrywania ataków brute force i reagowania na nie.

Zgodnie z modelem zewnętrznym interfejs API opiera się na przypadkach użycia danych przez konsumentów, a nie na strukturze istniejących danych w systemach backendu. Bezpieczeństwo to kluczowy element podczas projektowania interfejsów API dla konsumentów zewnętrznych. Tradycyjnie systemy backendu nie są projektowane z użyciem wystarczająco silnych implementacji uwierzytelniania, aby zapewnić ekspozycję w sieciach publicznych. Właśnie dzięki Apigee w połączeniu z rozwiązaniem do zarządzania tożsamościami i dostępem może zapewnić skuteczne rozwiązania chroniące przed tym zagrożeniem.

Należy tu wziąć pod uwagę kilka głównych elementów. Omówimy je w kolejnych sekcjach:

  • Projektowanie zabezpieczeń: pełne wykorzystanie funkcji Apigee do implementacji wzorców uwierzytelniania
  • Zarządzanie: zapewnianie spójnego korzystania z zaprojektowanych wzorców uwierzytelniania we wszystkich opublikowanych usługach API
  • Bezpieczeństwo operacyjne: możliwość wykrywania podejrzanych lub nietypowych zachowań oraz próby obejścia lub brute-force uwierzytelnionych serwerów proxy interfejsu API

Projektowanie zabezpieczeń

Celem projektowania zabezpieczeń jest prawidłowa implementacja procesów uwierzytelniania i integracja z zewnętrznymi narzędziami do obsługi tożsamości. Projektowanie zabezpieczeń jest kluczowym etapem, który rozpoczyna się od zrozumienia odpowiedniego typu przepływu uwierzytelniania delegowanego, odpowiedniego do typu aplikacji, która będzie korzystać z punktów końcowych interfejsu API. Następnym krokiem jest określenie wraz z zespołem ds. tożsamości wzorców integracji do wdrożenia z Twoim rozwiązaniem w zakresie tożsamości.

Dokumenty RFC OpenID Connect i OAuth udostępniają wiele różnych przepływów uwierzytelniania delegowanego i uwierzytelniania, a także podmioty zaangażowane w te przepływy. To skomplikowany temat i nic nie dziwi, że uszkodzone uwierzytelnianie to jedno z najczęstszych zagrożeń OWASP API. Szczegółowe informacje o prawidłowej implementacji standardów tożsamości nie zostały uwzględnione w tym dokumencie, ale Apigee udostępnia wiele dodatkowych zasobów, które pozwalają lepiej zrozumieć procesy OAuth, takie jak e-book i transmisja internetowa oraz przykładowa implementacja.

Zasady uwierzytelniania

Zasady Apigee, które pomagają w rozwiązaniu problemów z tożsamością i uwierzytelnianiem, obejmują:

Zarządzanie ruchem

Opisane poniżej funkcje zarządzania ruchem w Apigee pomagają chronić użytkowników przed atakami brute-force:

  • Zasada Spike Arrest służąca do ustawiania ogólnego limitu średniej kroczącej dla serwera proxy interfejsu API
  • Zasady limitów do ustawiania szczegółowych limitów liczby żądań do serwerów proxy interfejsów API na podstawie limitów zdefiniowanych przez klucze aplikacji, deweloperów lub limity usług API
  • Zasady buforowania, które umożliwiają buforowanie zapisanych tokenów dostępu na podstawie zdefiniowanego czasu ważności oraz możliwość invalidate danych logowania w pamięci podręcznej (na przykład w przypadku naruszenia ważnego tokena dostępu).

Zarządzanie

Bezpieczeństwo to proces ciągły, a nie projekt typu „set i zapomnieć”. Jedną z najczęstszych przyczyn naruszeń zabezpieczeń jest nieprawidłowa konfiguracja. Po zdefiniowaniu przepływów uwierzytelniania, wzorców integracji tożsamości i zasad zarządzania ruchem związanym z uwierzytelnianiem bardzo ważne jest, aby były one prawidłowo i spójnie zaimplementowane.

Apigee udostępnia wiele funkcji i narzędzi, które zapewniają integralność implementacji i zapobiegają błędów konfiguracji.

Kontrola dostępu oparta na rolach (RBAC)

Niezależnie od tego, czy działasz w dużej firmie czy małym startupie, uniknięcie błędów konfiguracji zaczyna się od zapewnienia, że tylko odpowiednie osoby i zespoły mają dostęp do konfiguracji serwera proxy interfejsu API i mogą je modyfikować. Programy dotyczące interfejsów API są obsługiwane przez wielodyscyplinarne zespoły w organizacji. Bardzo ważne jest, aby każdy zespół miał wyłącznie uprawnienia niezbędne do wykonywania swoich zadań w ramach korzystania z interfejsu API.

Apigee udostępnia funkcje, które umożliwiają zarządzanie dostępem na podstawie ról, umożliwiając przypisywanie użytkowników do wstępnie zdefiniowanych ról lub tworzenie ról niestandardowych odpowiednich dla zespołów zajmujących się interfejsami API. Aby można było bezpiecznie skalować program interfejsów API, poprawne definiowanie ról i zarządzanie nimi ma kluczowe znaczenie. Możesz też używać federacji do integracji z istniejącym katalogiem firmowym i aby ograniczyć konieczność zarządzania drugim zestawem danych logowania administratora w Apigee.

Przepływy współdzielone

Przepływy współdzielone pozwalają definiować zasady i zasoby w obiektach wielokrotnego użytku, które można wdrożyć w serwerach proxy interfejsów API. Być może udało Ci się np. wspólnie z zespołami ds. bezpieczeństwa zaprojektować wiele wzorców uwierzytelniania na podstawie typu aplikacji, która korzysta z interfejsu API. Programista interfejsów API nie musi być ekspertem ds. tożsamości, aby ponownie użyć tej funkcji. Musi tylko znać prawidłowy proces udostępniania, aby dodać go do dotychczasowej konfiguracji serwera proxy interfejsu API za pomocą zasady objaśnienia przepływu.

Rysunek: przepływy współdzielone to pakiety zasad wielokrotnego użytku i logiki warunkowej, które umożliwiają zachowanie wzorca złożonego.

Raportowanie zabezpieczeń

Gdy będziesz mieć pewność, że tylko odpowiednie osoby w organizacji mogą modyfikować wzorce uwierzytelniania, i zdefiniujesz współdzielone przepływy uwierzytelniania, musisz zadbać o to, aby serwery proxy interfejsów API utworzone przez Twoje zespoły zajmujące się interfejsami API konsekwentnie używały tych wzorców uwierzytelniania.

Nowa funkcja Apigee Advanced API Ops obejmuje zaawansowane raportowanie zabezpieczeń, która umożliwia zespołom operacyjnym i ds. zabezpieczeń łatwe wyświetlanie raportów na temat wszystkich serwerów proxy interfejsów API, i koncentruje się na zgodności z zasadami zabezpieczeń, takimi jak korzystanie z współdzielonych przepływów. Raportowanie, logowanie i alerty to kluczowy element zabezpieczeń interfejsu API, który zostanie szczegółowo omówiony w sekcji API10: niewystarczające logowanie. Jednak z punktu widzenia zapobiegania zagrożeniom związanym z uwierzytelnianiem, bardzo przydatny jest zapewnienie zgodności z określonymi przez Ciebie standardami uwierzytelniania wdrożonymi jako przepływy współdzielone.

Bezpieczeństwo operacyjne

Gdy interfejsy API zostaną wdrożone z wykorzystaniem odpowiednich wzorców uwierzytelniania z podstawowym zarządzaniem ruchem, zespół SecOps musi mieć możliwość monitorowania podejrzanej aktywności i reagowania na nią, co często zaczyna się od prób przejęcia danych uwierzytelniających.

Apigee Sense

Apigee Sense chroni interfejsy API przed niechcianym ruchem związanym z żądaniami, w tym atakami ze złośliwych klientów. Apigee Sense analizuje ruch związany z żądaniami do interfejsu API, identyfikując wzorce, które mogą przedstawiać niechciane żądania. Korzystając z tej analizy, możesz zidentyfikować klientów wysyłających niechciane żądania, a następnie podjąć działania, aby zezwolić na te żądania, zablokować je lub oznaczyć. Kolejne funkcje Sense będzie obejmować możliwość automatycznego włączania weryfikacji reCAPTCHA w przypadku podejrzanego ruchu.

Apigee Sense pozwala chronić swoje interfejsy API przed wzorcami żądań, w tym:

  • Zautomatyzowane zachowanie, które łączy się z działaniami ludzkimi
  • Uporczywe próby z tego samego adresu IP
  • Nietypowe odsetek błędów
  • Podejrzane prośby klientów
  • Indeksowanie danych
  • Zbieranie kluczy i uwierzytelnianie brute-force
  • Serie aktywności
  • Wzorce geograficzne

Zaawansowane operacje interfejsu API

Chociaż Sense zostało zaprojektowane specjalnie do wykrywania zagrożeń przypominających roboty i reagowania na nie, zaawansowane operacje interfejsu API obejmują zarówno wykrywanie anomalii, jak i zaawansowane alerty.

Wykrywanie anomalii polega na stosowaniu modeli sztucznej inteligencji (AI) i systemów uczących się (ML) do historycznych danych interfejsów API. Wykrywanie anomalii może w czasie rzeczywistym generować alerty w przypadku scenariuszy, o których nawet nie pomyślałeś(-aś), aby zwiększyć produktywność i skrócić średni czas rozwiązywania problemów z interfejsem API.

Zaawansowane operacje interfejsu API wykorzystują istniejący mechanizm alertów monitorowania interfejsów API, dodając następujące zaawansowane typy alertów:

  • Alerty o całkowitym natężeniu ruchu. Podnosi alert, gdy w danym okresie natężenie ruchu zmieni się o określoną wartość procentową. Możesz na przykład zwiększać na godzinę wzrost ruchu o co najmniej 5% na godzinę lub spadek o 10% lub więcej na tydzień
  • Alerty o anomalii Edge wykrywa problemy z ruchem i wydajnością, zamiast wymagać ich samodzielnego określania. Następnie możesz zgłosić alert o tych anomaliach.
  • Alerty o wygaśnięciu TLS Zgłasza powiadomienie, gdy certyfikat TLS zbliża się do wygaśnięcia

API3:2019 Nadmierna ekspozycja danych

Opis zagrożenia

Opublikowany interfejs API może ujawnić więcej danych, niż jest to konieczne. W związku z tym, że aplikacja kliencka przeprowadzi niezbędne filtrowanie, Jeśli osoba przeprowadzająca atak bezpośrednio wyśle zapytanie do interfejsu API, może uzyskać dostęp do danych wrażliwych.

Jedną z przyjętych w Apigee zasad projektowania interfejsów API „outside-in” jest spójność danych. Współpracuj z projektantami i programistami UX, aby udostępniać dane tylko za pomocą interfejsów API, które są niezbędne w interfejsie Twojej aplikacji. Systemy backendu nie zostały utworzone pod kątem publicznych wzorców wykorzystania, dlatego jednym z pierwszych zadań projektowania interfejsów API w Apigee jest ograniczenie ilości danych ujawnianych do minimum niezbędnego do zapewnienia świetnych usług API klientom i programistom.

Kolejną z zasad projektowania Apigee jest wielokrotne wykorzystanie. Poza problemami dotyczącymi bezpieczeństwa korzystanie przez aplikację do filtrowania danych przekazywanych przez interfejs API wymaga przeniesienia tej logiki filtrowania na każdą platformę, na którą tworzysz aplikację.

Z perspektywy bezpieczeństwa wynika to z przekazania egzekwowania autoryzacji aplikacji, często jednak w ramach platformy lub systemu operacyjnego, nad którymi nie masz kontroli. W interfejsach API1 i API2 przeanalizowaliśmy, jak ważne jest prawidłowe wdrożenie uwierzytelniania i autoryzacji w celu uniknięcia nieautoryzowanego dostępu do danych.

W kolejnych sekcjach omawiamy:

  • Przepisz żądania i odpowiedzi do usług backendu, aby zminimalizować ryzyko ujawnienia danych
  • Zaimplementuj obsługę błędów, aby zapobiec udostępnianiu osobom przeprowadzającym ataków poufnych informacji ze środowiska o usługach backendu poufnych komunikatów o błędach.

Przepisywanie odpowiedzi i żądań

Systemy backendu nie są zwykle zaprojektowane do użytku w aplikacjach publicznych lub w niezaufanych sieciach publicznych. Usługa Apigee Edge została zaprojektowana tak, aby umożliwić wdrażanie publicznych usług interfejsu API przez ochronę backendów przed nadmiernym ujawnianiem danych.

W tym celu Apigee wykorzystuje 3 kluczowe zasady:

  • Przypisz wiadomość
  • Objaśnienia kodu
  • Obsługa błędów

Przypisz zasadę dotyczącą wiadomości

Zasada Przypisz wiadomość zmienia lub tworzy nowe wiadomości z żądaniami i odpowiedziami podczas procesu serwera proxy interfejsu API. Zasady te umożliwiają wykonywanie na takich wiadomościach tych czynności:

  • Dodawanie do wiadomości nowych parametrów formularzy, nagłówków lub parametrów zapytania
  • Kopiowanie istniejących właściwości z jednej wiadomości do drugiej
  • Usuwanie nagłówków, parametrów zapytań, parametrów formularzy lub ładunków wiadomości z wiadomości
  • Ustaw wartość właściwości istniejących w wiadomości

Za pomocą funkcji Przypisz wiadomość zwykle dodajesz, zmieniasz i usuwasz właściwości żądania lub odpowiedzi. Jednak za pomocą funkcji Przypisz wiadomość możesz też utworzyć niestandardowe żądanie lub wiadomość z odpowiedzią i przekazać je do alternatywnego miejsca docelowego zgodnie z opisem w sekcji Tworzenie niestandardowych wiadomości z żądaniami.

Złożone przepisywanie z użyciem niestandardowego kodu

W przypadku złożonych reguł obsługi i przepisywania danych, których złożoność wykracza poza możliwości zasady przypisywania wiadomości, możesz użyć języków proceduralnych, takich jak JavaScript, Java czy Python. Możesz dodać niestandardowy kod do serwera proxy interfejsu API, a następnie wywoływać go z zasad dodanych do procesu serwera proxy. Obsługa kodu procedurowego ma ułatwiać wdrażanie złożonej obsługi zmiennych przepływu, błędów oraz treści żądań i odpowiedzi.

Kody proceduralne pozwalają:

  • Tworzenie lub modyfikowanie złożonych wartości treści, takich jak wartości żądania i odpowiedzi.
  • Przepisz adresy URL, na przykład w celu zamaskowania adresu URL docelowego punktu końcowego.

Apigee Edge obejmuje oddzielne zasady dla obsługiwanych języków: zasady dotyczące JavaScriptu, zasady dotyczące objaśnień w języku Java i zasady języka Python.

Obsługa błędów

Apigee umożliwia niestandardową obsługę wyjątków za pomocą zasady typu Zgłaszanie błędu. Zasada Zgłaszanie błędu, która jest wariantem zasady przypisywania wiadomości, umożliwia generowanie niestandardowej odpowiedzi o błędzie w odpowiedzi na warunek błędu.

Przepływy współdzielone

Przepływy współdzielone mogą służyć do egzekwowania standaryzacji komunikatów o błędach. Na przykład te same skonfigurowane zasady, które wykrywają konkretny kod błędu HTTP z backendu, mogą zostać użyte do przepisania odpowiedzi o błędzie w taki sposób, aby zwracała ogólny komunikat o błędzie.

API4:2019 Brak zasobów i ograniczenia liczby żądań

Opis zagrożenia

Brak wdrożenia zasad ograniczających liczbę żądań może spowodować atak typu „odmowa usługi” na backendzie.

To zagrożenie można łatwo rozwiązać, korzystając z tych funkcji Apigee:

  • Zasady dotyczące limitów i Spike Arrest jako narzędzia zapobiegawcze nakładające limity ruchu na przychodzące żądania do interfejsu API
  • Apigee Sense – dynamiczne wykrywanie ataków przeprowadzanych przez boty i reagowanie na nie.
  • Zaawansowane monitorowanie i alerty dotyczące interfejsów API jako narzędzia detektywistyczne pozwalające otrzymywać alerty o trwających atakach DDoS

Ograniczenie liczby żądań za pomocą zasad dotyczących limitów i zwiększenia liczby aresztowań

Apigee udostępnia 2 zasady ograniczania liczby żądań:

  • Zatrzymanie szczytu udostępnia ogólne zasady zdefiniowane na poziomie serwera proxy interfejsu API dotyczące częstotliwości ograniczania łącznej liczby żądań przychodzących do backendu
  • Limity to szczegółowe narzędzie do egzekwowania zasad na poziomie serwera proxy interfejsu API lub usługi API.

aresztowanie na głowie

Zasada Spike Arrest chroni przed wzrostem natężenia ruchu. Ta zasada ogranicza liczbę żądań przetwarzanych przez serwer proxy interfejsu API i wysyłanych do backendu, chroniąc przed opóźnieniami w wydajności i przestojami przy użyciu średniej kroczącej zdefiniowanej w ramach zasady.

Limity

Zasada Limit pozwala skonfigurować liczbę wiadomości z żądaniami, na które serwer proxy interfejsu API zezwala w określonym czasie, na przykład w minutach, godzinach, dniach, tygodniach lub miesiącach. Możesz ustawić taki sam limit dla wszystkich aplikacji uzyskujących dostęp do serwera proxy interfejsu API lub możesz go ustawić na podstawie:

  • Usługa, która zawiera serwer proxy interfejsu API
  • Aplikacja żądająca interfejsu API
  • Deweloper aplikacji
  • Wiele innych kryteriów

Ta zasada jest bardziej szczegółowa niż działanie Spike’a i zwykle należy używać jej równocześnie.

Wykrywanie botów za pomocą Apigee Sense

Apigee Sense umożliwia bezpośrednie zezwalanie, blokowanie lub oznaczanie żądań pochodzących od określonych klientów, zakresów adresów IP lub organizacji autonomicznych systemów na podstawie klientów lub lokalizacji wykazujących złośliwe bądź podejrzane zachowanie. Apigee Edge stosuje te działania do żądań przed przetworzeniem ich przez serwery proxy interfejsu API. Na przykład zakres adresów IP lub konkretny klient wykazujący się złośliwym zachowaniem mogą zostać wykryte, a następnie zablokowane lub oznaczone.

Wykrywanie zagrożeń za pomocą zaawansowanego monitorowania operacji interfejsu API

Używaj alertów dotyczących ruchu, aby wysyłać powiadomienie o zmianach ruchu w środowisku, serwerze proxy lub regionie o określoną wartość procentową w danym okresie. Ta funkcja może dynamicznie generować alert, gdy ruch znacząco odbiega od oczekiwanej przepustowości, tak jak w przypadku ataku DDoS. Alerty te mogą być łatwo wysyłane do rozwiązania do logowania i monitorowania innej firmy.

API5:2019 Uszkodzona autoryzacja na poziomie funkcji

Opis zagrożenia

To zagrożenie jest odmianą w interfejsie API1 i jest również luką w zabezpieczeniach autoryzacji. W przypadku tego zagrożenia haker może wykonywać działania, wysyłając żądania do funkcji, do których nie ma dostępu. Na przykład osoba przeprowadzająca atak może zmodyfikować lub usunąć dane, do których ma uprawnienia tylko wtedy, gdy punkt końcowy interfejsu API nie weryfikuje czasownika żądania HTTP. W tym celu może zastąpić żądanie GET poleceniem PUT lub DELETE. Jeśli natomiast nie wprowadzisz wystarczająco restrykcyjnej kontroli dostępu do ścieżki identyfikatora URI zasobu interfejsu API, punkt końcowy API może umożliwić atakującemu wyświetlenie danych innego użytkownika po prostu zmianę ścieżki w żądaniu.

Ten rodzaj zagrożenia podkreśla wartość wykorzystania Apigee jako warstwy zapośredniczenia i abstrakcji, ponieważ wiele systemów backendu, które nie zostały zaprojektowane pod kątem dostępu publicznego, może domyślnie udostępniać jeden punkt końcowy do wykonywania wielu funkcji logiki biznesowej, w tym nawet funkcji administracyjnych o wysokim ryzyku.

Elementy koncepcyjne pomagające zmniejszyć prawdopodobieństwo tego zagrożenia są zwykle podzielone na:

  • Co jest chronione? Zastanów się nad swoją strategią dotyczącą interfejsu API i zaimplementuj logiczną segmentację funkcji, korzystając ze sprawdzonych metod opartych na REST, aby zaprojektować ścieżki i zasoby udostępniane przez serwery proxy, usługi i funkcje aplikacji Apigee API.
  • Kto ma dostęp do Twoich zasobów interfejsu API? Zdefiniuj profile klientów wysokiego poziomu i wdróż domyślne uprawnienia dostępu z „najniższymi uprawnieniami”, korzystając z niektórych funkcji uwierzytelniania i autoryzacji Apigee opisanych w API1 i API2.
  • Jak egzekwowane są zasady dostępu? Używaj przepływów warunkowych i błędów do weryfikowania ścieżki adresu URL i czasownika wszystkich żądań do interfejsu API.

Rysunek: ten diagram przedstawia egzekwowanie autoryzacji na poziomie funkcji w Apigee z użyciem zakresów udostępnionych w tokenie dostępu jako uprawnień.

Segmentacja logiczna z serwerami proxy, usługami i aplikacjami API

Apigee udostępnia wysoce elastyczne narzędzie do logicznej segmentacji zasobów interfejsu API, dzięki czemu serwery proxy interfejsu API można połączyć w pakiet z dowolną liczbą usług interfejsu API, z których korzystają deweloperzy aplikacji, którzy mogą rejestrować aplikacje korzystające z Twoich usług interfejsu API. Zasady dostępu można definiować na dowolnym z tych poziomów.

Aby wdrożyć skuteczną funkcjonalną autoryzację i podział na segmenty, konieczne jest zdefiniowanie strategii dotyczącej produktów w interfejsie API. Częścią tego istotnego i ciągłego procesu jest określenie „kto” i „co” w usługach API. Spojrzenie na zasoby interfejsu API z punktu widzenia klienta i dewelopera, a następnie określenie, które typy żądań będą dozwolone, czyli do poziomu zasobu ścieżki i czasownika HTTP.

Rysunek: zasoby interfejsu API połączone z usługą API mogą pochodzić z jednego lub wielu interfejsów API, dzięki czemu możesz mieszać i dopasowywać zasoby, aby utworzyć poziomy wykorzystania i granice autoryzacji.

Kontrola dostępu na poziomie funkcji z zakresami OAuth i deklaracjami JWT

Opisane powyżej metody autoryzacji w przypadku uszkodzenia autoryzacji obiektów w interfejsie API1:2019 odnoszą się do szczegółowej kontroli dostępu na poziomie obiektów, jednak równie ważne jest określenie przybliżonej kontroli dostępu na poziomie funkcji. Czy użytkownik wysyłający prośbę może w ogóle poprosić o tę ścieżkę adresu URL? Ten typ zasad jest często definiowany dla profilu użytkownika (klienta, pracownika, administratora, wewnętrznego dewelopera lub zewnętrznego dewelopera).

Aby zmniejszyć ryzyko nieprawidłowej konfiguracji, skontaktuj się ze swoim zespołem ds. zabezpieczeń i zadbaj o to, by potwierdzenia dotyczące użytkownika wysyłającego żądanie (za pomocą zakresów OAuth lub deklaracji JWT) znajdowały się w tokenie dostępu.

Wysyłanie żądań weryfikacji za pomocą przepływów warunkowych

Na poziomie podstawowym wywołanie interfejsu API REST składa się z tych elementów:

  • Punkt końcowy
  • Zasób
  • Czasownik działania
  • Dowolna liczba dodatkowych atrybutów żądania, takich jak parametry zapytania

Rodzaj ataku opisany w tym zagrożeniu jest zwykle spowodowany niewystarczającym filtrowaniem żądania do interfejsu API, co pozwala atakującemu wykonać nieautoryzowane działania lub uzyskać dostęp do chronionego zasobu. Oprócz logiki warunkowej, która umożliwia filtrowanie żądań na podstawie tokenów dostępu lub deklaracji, Apigee umożliwia wdrożenie logiki filtrowania na podstawie samego żądania.

Gdy już dobrze zrozumiesz i zdefiniujesz logikę biznesową usługi API oraz funkcje dozwolone przez interfejsy API, następnym krokiem jest ograniczenie wszelkich żądań, które nie spełniają tych wymagań, za pomocą tych funkcji Apigee:

  • Logika warunkowa i zasady podnoszenia błędów w celu ograniczenia ścieżek zasobów lub czasowników na dowolnym etapie konfiguracji przepływu serwera proxy
  • Zasady ochrony przed zagrożeniami w JSON i XML, które chronią przed atakami opartymi na treści przy użyciu uszkodzonych ładunków żądań JSON lub XML.

API6:2019 – masowe przypisanie

Opis zagrożenia

Niefiltrowane dane dostarczane przez interfejsy API do aplikacji klienckich pozwalają hakerom odgadnąć właściwości obiektów za pomocą żądań lub stosować konwencje nazewnictwa punktów końcowych w celu uzyskania wskazówek, gdzie należy przeprowadzić nieautoryzowaną modyfikację lub uzyskać dostęp do właściwości obiektów danych przechowywanych w backendzie.

Zagrożenie to pojawia się, gdy do klienta trafiają niefiltrowane dane (zwykle w formacie JSON lub XML), co pozwala atakującemu odgadnąć szczegóły implementacji systemów backendu, a także nazwy właściwości elementów poufnych danych. Wynik tego typu ataku może umożliwić hakerowi odczytywanie nieodpowiednich danych lub manipulowanie nimi, a w najgorszym razie może też doprowadzić do powstania luk w zabezpieczeniach podczas zdalnego uruchamiania kodu.

Zezwolenie na ten rodzaj zagrożenia zwykle wymaga spełnienia 2 aspektów:

  • Perspektywa projektowania interfejsów API. Nigdy nie polegaj na logice aplikacji do filtrowania danych po stronie klienta, ponieważ aplikacje mogą zostać wykorzystane przez hakerów i uznać je za zaufane. Zawsze projektuj schemat danych interfejsu API w taki sposób, aby udostępniać jak najmniejszą ilość danych niezbędnych do włączenia usługi interfejsu API.
  • perspektywa wdrożenia interfejsu API. Zaimplementuj filtrowanie danych i weryfikację schematu, aby zapobiec nieumyślnemu ujawnieniu poufnych danych aplikacji klienckiej.

Apigee udostępnia kilka przydatnych funkcji, które zapewnią niezawodną implementację filtrowania danych w interfejsach API.

Zasada filtrowania specyfikacji OpenAPI

Zasada OASValidation (walidacja specyfikacji OpenAPI) pozwala zweryfikować przychodzące żądanie lub wiadomość z odpowiedzią na podstawie specyfikacji OpenAPI 3.0 (JSON lub YAML). Zasady te umożliwiają:

  1. Zaprojektuj swój interfejs API, tworząc specyfikację OpenAPI (OAS)
  2. Wdróż niezbędną logikę zapośredniczenia, zabezpieczeń i buforowania, aby bezpiecznie udostępniać usługę API z backendu za pomocą Apigee
  3. Weryfikuj przychodzące żądania pod kątem schematu danych zdefiniowanego w specyfikacji OAS, w tym ścieżki bazowej, czasownika, zasady dotyczącej wiadomości z żądaniem i parametrów.

Zasada weryfikacji wiadomości SOAP

Zasada weryfikacji wiadomości SOAP umożliwia weryfikację żądań opartych na języku XML przez weryfikację wiadomości XML w odniesieniu do schematu XSD lub weryfikację komunikatu SOAP w odniesieniu do definicji WSDL. Dodatkowo możesz użyć zasad weryfikacji wiadomości, aby potwierdzić, że ładunek wiadomości w formacie JSON lub XML jest poprawnie sformułowany, co obejmuje weryfikację tych elementów w wiadomości XML lub JSON:

  • Jest 1 element główny.
  • Treść nie zawiera niedozwolonych znaków.
  • Obiekty i tagi są prawidłowo zagnieżdżone
  • Jednakowe tagi początkowe i końcowe

API7:2019 – nieprawidłowa konfiguracja zabezpieczeń

Opis zagrożenia

Błędy w konfiguracji zabezpieczeń są zwykle spowodowane niezabezpieczonymi konfiguracjami domyślnymi, niepełnymi lub doraźnymi konfiguracjami, otwartą chmurą pamięci masowej, niewłaściwie skonfigurowanymi nagłówkami HTTP, zbędnymi metodami HTTP, mniej rygorystycznym udostępnianiem zasobów między źródłami (CORS) oraz szczegółowymi komunikatami o błędach zawierającymi informacje poufne. Osoby przeprowadzające atak często próbują znaleźć nienaprawione błędy, wspólne punkty końcowe lub niechronione pliki i katalogi, aby uzyskać nieautoryzowany dostęp lub wiedzę o systemie, który chcą atakować. Błędy konfiguracji zabezpieczeń mogą nie tylko ujawnić poufne dane użytkownika, ale też szczegóły systemu, które mogą prowadzić do przejęcia całego serwera. Oprócz tego niektóre przypadki użycia luk w zabezpieczeniach błędów konfiguracji zabezpieczeń mogą obejmować:

  • Błędna konfiguracja protokołu TLS
  • Komunikaty o błędach ze zrzutami stosu
  • Systemy bez poprawek
  • Panele zarządzania serwerem lub miejscem na dane

Aby rozwiązać problemy związane z nieprawidłowymi konfiguracjami zabezpieczeń i je rozwiązać, są to m.in.:

  1. Stworzenie i ustandaryzowanie procesów wzmacniania i zabezpieczania
  2. opracowanie zarządzania ekosystemem interfejsów API,
  3. Ograniczenie dostępu administracyjnego oraz włączanie kontroli i alertów

Przepływy współdzielone i punkty zaczepienia

Apigee obsługuje koncepcję przepływu współdzielonego, który umożliwia programistom interfejsów API łączenie zasad i zasobów w grupę wielokrotnego użytku. Dzięki zgromadzeniu funkcji wielokrotnego użytku w jednym miejscu wspólny proces pomaga zapewnić spójność, skrócić czas programowania i ułatwić zarządzanie kodem. Możesz uwzględnić wspólny przepływ w poszczególnych serwerach proxy API lub zrobić krok dalej i umieścić współdzielone przepływy w punktach zaczepienia przepływów, aby automatycznie wykonywać logikę wspólnego przepływu dla każdego serwera proxy interfejsu API wdrożonego w tym samym środowisku jako przepływ udostępniony.

Raportowanie zabezpieczeń interfejsu API

Organizacje starają się opracować platformę zarządzania, dlatego Apigee udostępnia funkcje raportowania bezpieczeństwa interfejsów API, co pomaga zespołom operacyjnym widzieć, jakich atrybutów zabezpieczeń potrzebują atrybuty zabezpieczeń interfejsów API. Dzięki temu:

  • Zapewnij zgodność z zasadami zabezpieczeń i wymaganiami dotyczącymi konfiguracji
  • Ochrona danych wrażliwych przed nadużyciami wewnętrznymi i zewnętrznymi
  • Proaktywne identyfikowanie, diagnozowanie i rozwiązywanie incydentów związanych z bezpieczeństwem

Raportowanie zabezpieczeń Apigee udostępnia szczegółowe statystyki dla zespołów operacyjnych, które pozwalają zapewnić zgodność z zasadami i wymaganiami dotyczącymi konfiguracji, chronić interfejsy API przed nadużyciami wewnętrznymi i zewnętrznymi oraz szybko identyfikować i rozwiązywać incydenty związane z bezpieczeństwem.

Dzięki raportom zabezpieczeń administratorzy zabezpieczeń mogą szybko sprawdzić, jak serwery proxy interfejsów API są skonfigurowane pod kątem zabezpieczeń, a także sprawdzić warunki działania, które mogą mieć wpływ na bezpieczeństwo serwera proxy. Korzystając z tych informacji, możesz dostosować konfigurację, aby zapewnić odpowiedni poziom zabezpieczeń dla każdego serwera proxy.

Monitorowanie interfejsów API

Apigee zapewnia kompleksową platformę monitorowania interfejsów API, która uzupełnia funkcje raportowania zabezpieczeń. Monitorowanie interfejsów API umożliwia organizacjom proaktywne wykrywanie problemów z ruchem przez interfejsy API i wydajnością. Apigee API Monitoring współpracuje z Apigee Edge dla Public Cloud, aby dostarczać kontekstowe statystyki wydajności interfejsu API w czasie rzeczywistym, szybko diagnozować problemy i ułatwiać działania naprawcze w celu zapewnienia ciągłości działania.

Rysunek: Apigee API Monitoring udostępnia wiele narzędzi do monitorowania, badania i rozwiązywania problemów. Wykorzystuje najlepsze w swojej klasie funkcje analityczne Google Cloud Platform.

Apigee Sense

Apigee Sense pomaga chronić interfejsy API przed niechcianym ruchem związanym z żądaniami, w tym atakami ze złośliwych klientów. Apigee Sense analizuje ruch związany z żądaniami do interfejsu API, identyfikując wzorce, które mogą przedstawiać niechciane żądania.

Dzięki tej analizie organizacje mogą identyfikować klientów wysyłających niechciane żądania, a następnie podejmować działania mające na celu dopuszczenie, blokowanie lub oznaczanie tych żądań. Apigee Sense pozwala chronić interfejsy API przed wzorcami żądań, które obejmują:

  • Zautomatyzowane zachowanie, które łączy się z działaniami ludzkimi
  • Uporczywe próby z tego samego adresu IP
  • Nietypowe odsetek błędów
  • Podejrzane prośby klientów
  • Indeksowanie danych
  • Zbieranie kluczy
  • Serie aktywności
  • Wzorce geograficzne

Wstrzyknięcie interfejsu API8:2019

Opis zagrożenia

Wstrzyknięcie do żądań do interfejsu API danych, takich jak SQL, NoSQL, parsery XML, ORM, LDAP, polecenia systemu operacyjnego i JavaScript, może spowodować wykonanie niezamierzonych poleceń lub nieautoryzowany dostęp do danych. Osoby przeprowadzające atak przekazują do interfejsu API szkodliwe dane za pomocą dowolnych dostępnych wektorów wstrzykiwanych – takich jak bezpośrednie dane wejściowe, parametry, zintegrowane usługi itp. i oczekując, że zostaną one wysłane do interpretera. Osoby przeprowadzające atak mogą łatwo wykryć te błędy podczas przeglądania kodu źródłowego za pomocą skanerów luk w zabezpieczeniach i mechanizmów fuzzerów. Pomyślne wstrzyknięcie może prowadzić do ujawnienia informacji, które będzie miało wpływ na poufność i utratę danych, a w niektórych przypadkach może też doprowadzić do ataku DoS.

Sprawdzone metody eliminowania błędów wstrzykiwania/ataków obejmują ścisłe zdefiniowanie danych wejściowych, takich jak schematy, typy, wzorce ciągów znaków, sprawdzenie poprawności danych wejściowych, ograniczenie ich kontroli i egzekwowanie ich w czasie działania. Platforma Apigee umożliwia weryfikowanie przychodzących danych za pomocą filtrów, aby zezwolić na tylko prawidłowe wartości każdego parametru wejściowego.

Apigee Edge, pełniąca funkcję serwera dla przychodzących żądań do interfejsu API, sprawdza, czy struktura ładunku mieści się w akceptowalnym zakresie. Jest to tzw. kontrola limitu. Możesz skonfigurować serwer proxy interfejsu API, tak aby procedura weryfikacji danych wejściowych przekształcała dane wejściowe w celu usunięcia niebezpiecznych sekwencji znaków i zastąpienia ich bezpiecznymi wartościami.

Zasady ochrony wyrażeń regularnych

Zasada RegularExpressionProtection wyodrębnia informacje z wiadomości (np. ścieżka URI, parametr zapytania, nagłówek, parametr formularza, zmienna, ładunek XML lub ładunek JSON) i ocenia tę treść pod kątem zdefiniowanych wstępnie wyrażeń regularnych. Jeśli dowolne z określonych wyrażeń regularnych otrzyma wartość prawda, wiadomość zostanie uznana za zagrożenie i odrzucona. Wyrażenie regularne (w skrócie) to zestaw ciągów znaków określających wzór w ciągu znaków. Wyrażenia regularne umożliwiają automatyczną ocenę treści pod kątem wzorców. Wyrażenia regularne mogą posłużyć na przykład do sprawdzenia, czy adres e-mail ma prawidłową strukturę.

Najczęściej używane jest RegularExpressionProtection do oceny ładunków JSON i XML pod kątem szkodliwych treści.

Żadne wyrażenie regularne nie wyeliminuje wszystkich ataków opartych na treściach, a wszystkie mechanizmy obronne wymagają połączenia różnych mechanizmów. W tej sekcji opisujemy kilka zalecanych wzorców uniemożliwiających dostęp do treści.

Istnieje kilka innych metod weryfikacji danych wejściowych dostępnych na platformie Apigee:

Zweryfikuj typy treści

Typ treści odnosi się do zawartości pliku przesyłanego przez HTTP i klasyfikowanego według dwuczęściowej struktury. Apigee zaleca zweryfikowanie typów treści żądania i odpowiedzi przy użyciu logiki warunkowej, jak opisano poniżej.

Raportowanie zabezpieczeń interfejsu API

Organizacje starają się opracować platformę zarządzania, dlatego Apigee zapewnia możliwości związane z raportowaniem zabezpieczeń interfejsów API, co ułatwia i daje zespołom operacyjnym wgląd potrzebny w zabezpieczaniu interfejsów API. Zapewnia zespołom operacyjnym wgląd w dane, których potrzebują atrybutów zabezpieczeń interfejsów API, aby:

  • Zapewnij zgodność z zasadami zabezpieczeń i wymaganiami dotyczącymi konfiguracji.
  • Ochrona danych wrażliwych przed nadużyciami wewnętrznymi i zewnętrznymi.
  • Aktywne identyfikowanie, diagnozowanie i rozwiązywanie incydentów związanych z bezpieczeństwem.

API9:2019 Niewłaściwe zarządzanie komponentami

Opis zagrożenia

Niewystarczające zarządzanie środowiskiem i segregacja środowiska umożliwiają hakerom dostęp do niezabezpieczonych punktów końcowych interfejsów API. Brak środków ochrony dotyczących zarządzania powoduje też niepotrzebne narażenie wycofanych zasobów.

To zagrożenie można rozwiązać, wykorzystując dojrzałe możliwości Apigee w zarządzaniu pełnym cyklem życia interfejsu API, co pozwala stworzyć kompleksowy model zarządzania umożliwiający współpracę między zespołami, a jednocześnie wprowadzić oddzielenie obowiązków między osobami odpowiedzialnymi za bezpieczeństwo a programistami interfejsów API. Ograniczenia i mechanizmy kontrolne można konfigurować i obsługiwać za pomocą:

Organizacje, środowiska i wersje: wirtualne i fizyczne bariery, które zapewniają izolację i proces bezpiecznej promocji w kontekście środowiska wykonawczego.

Kontrola dostępu oparta na rolach: tylko niezbędne osoby w zespołach ds. interfejsów API będą miały uprawnienia do zarządzania zmianami w konfiguracji i procesem awansowania.

Zarządzanie odbiorcami w dokumentacji interfejsu API: po opublikowaniu interfejsu API w portalu dla deweloperów możesz ograniczyć widoczność dokumentacji, zarządzając grupami odbiorców.

Punkty zaczepienia: możesz egzekwować globalne zasady i wzorce, którymi można zarządzać jako uprzywilejowane bariery, których programiści API nie mogą modyfikować.

Raportowanie zabezpieczeń: osoby zainteresowane w zakresie bezpieczeństwa mają kompleksowy wgląd w opublikowane interfejsy API i ich konfigurację pomocniczą. Zgodność z globalnymi zasadami zabezpieczeń może być skontrolowana i oceniana na podstawie profilu ryzyka każdego opublikowanego punktu końcowego interfejsu API.

Organizacje i środowiska

Artefakty konfiguracji, użytkowników i funkcje w Apigee można ograniczyć do określonych organizacji lub środowisk. Oznacza to, że platforma ma gotowe bariery, które można umieścić wokół interfejsów API i ich konfiguracji pomocniczej.

Organizacje: organizacja jest najemcą najwyższego poziomu w Apigee. Umożliwia pełną segregację ruchu, konfiguracji i użytkowników. Sprawdzoną metodą zarządzania jest utworzenie osobnych organizacji produkcyjnych i nieprodukcyjnych. Ta metoda pozwala uniknąć łączenia danych produkcyjnych, użytkowników i ruchu z niższymi środowiskami.

Środowiska: interfejsy API w Apigee można promować przez wiele stanów wdrożenia; każdy stan jest powiązany z kontekstem wykonania. W trakcie procesu awansowania nie jest wykonywany kontekst środowiska, co pozwala uniknąć ujawniania konfiguracji poufnych użytkowników bez uprawnień.

Wersje: wersje umożliwiają bezproblemowe promowanie interfejsów API i poszczególnych funkcji w środowiskach.

Kontrola dostępu oparta na rolach

Aby ograniczyć ryzyko związane z API9, konieczne jest określenie jasnych definicji i rozdzielenie obowiązków między osobami odpowiedzialnymi za bezpieczeństwo a deweloperami interfejsów API. Jak już wspomnieliśmy w tym dokumencie, Apigee ma elastyczne funkcje kontroli dostępu opartej na rolach, które pozwalają przypisywać uprawnienia do ról niestandardowych. W przypadku tego konkretnego zagrożenia można ograniczyć zakres ról do ograniczonych uprawnień w danej organizacji lub środowiskach albo z bardziej szczegółowych uprawnień konfiguracji. Zalecamy ograniczenie uprawnień pozwalających na zmianę stanu wdrożenia interfejsów API za pomocą środowisk, a także zadbać o to, by programiści nie mieli dostępu do globalnych bibliotek zabezpieczeń (punktów przepływu) i nie mogli ich modyfikować. Te ograniczone role zapobiegną niechcianym zmianom w globalnych zasadach zabezpieczeń, które mają szerokie zastosowanie zarówno do starszych, jak i obecnie opublikowanych punktów końcowych.

Zarządzanie odbiorcami na potrzeby dokumentacji interfejsu API

Portal dla programistów to kluczowy element sukcesu Twojej strategii dotyczącej interfejsów API. Pozwala przechowywać kompleksową dokumentację związaną z interfejsami API, w tym hosty i punkty końcowe, zasoby, operacje, schematy ładunków i nie tylko. W Apigee możesz grupować interfejsy API za pomocą konstrukcji usługi API. Usługi API są zdefiniowane według pakietów zasobów i operacji, które mieszczą się w tym samym kontekście biznesowym i zabezpieczeń (np. plan usług, domena firmy, kategoria, hierarchia firmy itp.).

Za pomocą zintegrowanego portalu dla programistów Apigee możesz publikować usługi API i ograniczać widoczność opublikowanych treści przez zarządzanie grupami odbiorców. Ta funkcja jest zgodna ze strategią segmentacji treści, która spełnia wymagania biznesowe i dotyczące bezpieczeństwa.

Haczyki

Procesy promowania i udostępniania interfejsów API muszą zawsze obejmować procesy zapewniania zgodności z zabezpieczeniami i certyfikacji. Aby była efektywna, zespoły zajmujące się interfejsami API używające odpowiednich narzędzi powinny być w stanie utworzyć bariery, które zapewniają oddzielenie zakresów odpowiedzialności i jednocześnie utrzymują elastyczne cykle publikowania.

Apigee umożliwia zwiększenie obowiązków związanych z zarządzaniem bezpieczeństwem przez egzekwowanie globalnych zasad za pomocą punktów przepływu. Te zasady globalne mogą być zarządzane jako uprzywilejowane bariery, których nie mogą modyfikować programiści interfejsów API, co gwarantuje oddzielenie odpowiedzialności i zwiększa elastyczność przez zastosowanie domyślnych zabezpieczeń, a co za tym idzie, zapewnienie zgodności wszystkich interfejsów API wdrożonych w danym środowisku wykonawczym.

Ilustracja: bariery uprzywilejowane można skonfigurować w Apigee za pomocą punktów zaczepienia przepływu i przepływów współdzielonych. Podmioty zajmujące się bezpieczeństwem są odpowiedzialne za zachowanie globalnych zasad związanych z bezpieczeństwem. Te funkcje gwarantują oddzielenie obowiązków i wspierają elastyczne cykle rozwoju.

Raportowanie zabezpieczeń

Audyty zabezpieczeń służą do oceny i testowania zasad zabezpieczeń, które mają chronić dane i cele biznesowe Twojej organizacji. Interfejsy API to ustandaryzowane publiczne lub prywatne interfejsy, które muszą być chronione za pomocą kompleksowego, a jednocześnie podlegającego kontroli modelu zarządzania zabezpieczeniami.

W Apigee masz dostęp do wyspecjalizowanych raportów o zabezpieczeniach, które pomagają zapewnić zgodność ze zdefiniowanymi zasadami i umożliwiają zespołom ds. bezpieczeństwa podejmowanie działań na podstawie kompleksowych statystyk dotyczących:

Ruch w środowisku wykonawczym: kompleksowy widok statystyk ruchu w interfejsach API, takich jak serwery docelowe, hosty wirtualne, konfiguracja TLS, zmiany ruchu w środowisku i nie tylko.

Konfiguracja: możliwość kontroli konfiguracji serwerów proxy interfejsu API, która zapewnia kompleksowy wgląd we wszystkie zasady egzekwowane na poziomie serwera proxy interfejsu API, a także spektrum egzekwowania przepływów współdzielonych powiązanych na poziomie organizacji lub serwera proxy.

Aktywność użytkowników: śledź operacje poufne wykonywane przez użytkowników platformy. Przeanalizuj podejrzaną aktywność, aby przejść do bardziej szczegółowego widoku podejrzanej aktywności.

API10:2019 Niewystarczające logowanie i monitorowanie

Opis zagrożenia

Niewystarczające logowanie, monitorowanie i alerty sprawiają, że trwające ataki nie są wykrywane, dlatego należy opracować strategię, aby uzyskać statystyki dotyczące krytycznych zdarzeń, które mają wpływ na Twoją firmę.

Strategie zarządzania zdarzeniami i logowaniem w interfejsach API powinny uwzględniać te sprawdzone metody:

  • Zasady zarządzania logami: dokumentuj i egzekwuj reguły, które pozwalają standaryzować i kontrolować szczegółowość logów, poziomy logów, integralność logów, scentralizowane repozytorium itp.
  • Zasady zarządzania zdarzeniami: gwarantuj, że każde zdarzenie powinno być możliwe do wyśledzenia do źródła. Poza tym wydarzenia powinny być sklasyfikowane według krytyczności i wpływu na działalność.
  • Raporty i kontrole: zainteresowane osoby ds. zabezpieczeń i operacji powinny mieć dostęp do logów i zdarzeń oraz reagować na nie w czasie rzeczywistym. Dodatkowo zainteresowane osoby mogą wykonywać cykle wzmacniania, aby dostosować wzorce wykrywania na podstawie danych historycznych

Apigee udostępnia niezbędne narzędzia do tworzenia kompleksowej strategii zarządzania zdarzeniami i logami. Do narzędzi tych należą:

Zasady logowania wiadomości: twórz strumienie logów na podstawie danych lub metadanych ruchu z interfejsu API. Możesz zdecydować o szczegółowości strumienia, korzystając z logiki warunkowej i szablonów wiadomości.

Pakiet Google Cloud Operation Suite: wykorzystaj gotową integrację z wysoce skalowalnymi narzędziami Google do monitorowania i logowania.

Zasada objaśnień dotyczących usługi: dodaje obsługę strumieni logów, które do wysyłania zdarzeń wymagają punktów końcowych HTTP.

Statystyki: uzyskaj dostęp do historycznych metadanych ruchu i analizuj je za pomocą gotowych raportów lub raportów niestandardowych. Twórz alerty i zarządzaj nimi na podstawie trendów i analizuj anomalie w ruchu.

Monitorowanie interfejsów API: jak już wspomnieliśmy, to narzędzie udostępnia funkcje tworzenia alertów, które można aktywować na podstawie zdarzeń krytycznych. Logi ruchu można dokładniej analizować i podejmować na ich podstawie działania.