10 największych zagrożeń interfejsu OWASP API

Wyświetlasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje

Ten dokument opisuje różne podejścia, których możesz używać w Apigee do rozwiązywania problemów z bezpieczeństwem zidentyfikowanych przez OWASP. Więcej informacji o dodatkowych podejściach dostępnych w Apigee znajdziesz w artykule OWASP Top 10 2021 (10 najważniejszych opcji zapobiegania atakom) w Google Cloud.

Wprowadzenie

OWASP to otwarta społeczność, która pomaga organizacjom w rozwijaniu, zakupie i utrzymywaniu zaufanych aplikacji i interfejsów API. W ramach projektu OWASP API Security organizacja OWASP publikuje najważniejsze zagrożenia dla bezpieczeństwa aplikacji internetowych i interfejsów API REST oraz podaje rekomendacje dotyczące radzenia sobie z tymi zagrożeniami.

W tym dokumencie omawiamy metody ochrony przed typowymi atakami na interfejs API, które zostały określone przez OWASP jako 10 największych zagrożeń dla bezpieczeństwa interfejsu API w 2019 r. Najczęstsze zagrożenia, które znalazły się na najnowszej liście, są spowodowane nieprawidłowym umieszczeniem elementów sterujących uwierzytelnianiem i autoryzacją, np. poleganiem na filtrowaniu danych zwracanych przez żądanie interfejsu API w aplikacji klienta, przez stosowanie nieprawidłowego wzorca polegającego na poleganiu na aplikacji klienta, która korzysta z kontroli dostępu.

Wraz z bardzo szybkim rozwojem ekosystemu interfejsów API nadużycia i nieprawidłowe użycie interfejsów API, które prowadzą do wycieku danych, stają się jednym z najczęstszych wektorów ataków. Bezpieczeństwo jest nadal kluczowym priorytetem Apigee, dlatego firma wprowadziła wiele nowych funkcji, takich jak zaawansowane operacje API, które obejmują funkcje raportowania zabezpieczeń i wykrywania anomalii. Jednak prawidłowe zaprojektowanie i wdrażanie funkcji zabezpieczeń Apigee jest kluczowe, aby zmniejszyć prawdopodobieństwo skutecznych ataków na interfejsy API.

Aplikacje dla konsumentów powinny być uznawane za niezawodne lub „publiczne”, ponieważ nie masz kontroli nad platformą, na której działa aplikacja. Zakładamy, że każda publiczna aplikacja może zostać naruszona i w związku z tym nie można ufać jej w zakresie egzekwowania kontroli dostępu (API1, API5), filtrowania danych odpowiedzi (API6) czy bezpiecznego przechowywania danych klienta (API2), takich jak klucze API lub tokeny dostępu. Niektóre rekomendacje wynikają z analizy 10 najczęściej występujących w 2019 r. zagrożeń OWASP:

  • Określ, jakie aplikacje klienckie będą korzystać z Twoich interfejsów API (SPA, mobilne lub oparte na przeglądarce) i zaprojektuj odpowiednie wzorce uwierzytelniania, autoryzacji i zabezpieczeń.
  • Zawsze używaj protokołu OAuth „public client” lub OpenID Connect (zalecamy używanie PKCE).
  • Zastanów się nad logiką biznesową aplikacji, najpierw zdefiniuj specyfikację OpenAPI, a potem zaprojektuj serwery proxy interfejsu API, aby filtrować wszystkie dane odpowiedzi z backendu w Apigee. Nigdy nie polegaj na logice kodu aplikacji na niższym poziomie.
  • Odfiltruj wszystkie żądania danych zawierające dane osobowe użytkownika, aby zezwalać tylko na dane z Twojego backendu należące do użytkownika, który wysłał żądanie.

API1:2019 Nieprawidłowa autoryzacja na poziomie obiektu

Opis zagrożenia

Niewystarczająca weryfikacja autoryzacji żądania dostępu do obiektu pozwala atakującemu na wykonanie niedozwolonego działania przez ponowne użycie tokena dostępu. Zagrożenie to jest spowodowane nieprawidłową konfiguracją weryfikacji autoryzacji. Apigee udostępnia zasady dotyczące klucza dostępu API, OAuth i tokenów sieciowych JSON (JWT), które pomagają chronić przed tą podatnością na ataki. Ważne jest jednak, aby te zasady były prawidłowo skonfigurowane, aby zapobiegać temu zagrożeniu.

Aby zapobiec temu zagrożeniu, ważne jest, aby zespoły zajmujące się tworzeniem aplikacji i bezpieczeństwem ściśle ze sobą współpracowały. Autoryzacja jest z natury złożonym zagadnieniem, a skuteczna autoryzacja z dokładnym kontrolowaniem wymaga dogłębnego zrozumienia logiki biznesowej aplikacji.

Z perspektywy wdrażania Apigee należy wziąć pod uwagę 2 główne aspekty:

  • Integralność tokena dostępu
  • Egzekwowanie kontroli dostępu

Integralność tokena dostępu

Należy sprawdzić, czy token dostarczony przez klienta przesyłającego żądanie nie został zmodyfikowany. W tym celu należy użyć prawidłowego przepływu OAuth lub OpenID Connect wraz z odpowiednim mechanizmem uwierzytelniania lub podpisywania. Apigee obsługuje wszystkie powszechnie stosowane przepływy OAuth.

Zasady weryfikacji tokenów dostępu Apigee obejmują:

Wymuszanie kontroli dostępu

Po zweryfikowaniu ważności tokena dostępu należy wdrożyć zasady kontroli dostępu, aby ocenić każde przychodzące żądanie interfejsu API pod kątem uprawnień dostępu tokena autoryzacji.

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

  • Wewnętrzny: korzystanie z przepływów warunkowych do oceny próśb o dostęp na podstawie roszczeń wyodrębnionych jako zmienne przepływu z tokena autoryzacji.
  • Przekazane: korzystanie z usługi do zarządzania dostępem innej firmy

Wewnętrzny model (przedstawiony na rysunku powyżej) jest zalecany, gdy model kontroli dostępu jest stosunkowo prosty. Na przykład, czy roszczenia wyodrębnione z tokena dostępu mogą być użyte do bezpośredniej oceny i autoryzacji żądania obiektu interfejsu API.

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

Przekazywanie (przedstawione na rysunku powyżej) jest zalecane, gdy: twierdzeń wyodrębnionych z tokena dostępu nie można bezpośrednio wykorzystać do autoryzacji żądania interfejsu API do obiektu w systemie backendowym lub w przypadku bardziej złożonych typów przepływu OAuth, które wymagają osobnego wywołania serwera autoryzacji w celu uzyskania tokena dostępu.

Za pomocą wyświetlenia usługi możesz poprosić o decyzję dotyczącą autoryzacji od usługi innej firmy lub uzyskać dodatkowe informacje o podmiocie żądającym, aby następnie podjąć decyzję dotyczącą kontroli dostępu za pomocą przepływu warunkowego.

API2:2019 Broken user authentication

Opis zagrożenia

Źle zaimplementowane zasady uwierzytelniania użytkowników umożliwiają atakującym podszywanie się pod prawdziwych użytkowników, ponieważ wykorzystują one błędy w implementacji uwierzytelniania. Oto kilka zasad uwierzytelniania, o których należy pamiętać podczas implementowania metod uwierzytelniania:

  • Zawsze uwierzytelniaj zarówno klienta użytkownika (aplikację), jak i użytkownika, który wysyła żądanie.
  • Używaj delegowanych wzorów uwierzytelniania i autoryzacji oraz unikaj przekazywania haseł bezpośrednio w żądaniu API.
  • Zawsze sprawdzaj podpis danych dostępu i upewnij się, że wszystkie używane dane dostępu mają zdefiniowany czas ważności.
  • zapobieganie atakom typu „siłowa próba” przez ustawienie limitów i wykorzystanie narzędzia Apigee Sense do wykrywania ataków typu „siłowa próba” napędzanych przez boty oraz reagowania na nie;

W ramach paradygmatu od zewnątrz do wewnątrz projektowanie interfejsu API jest oparte na przypadkach użycia danych przez użytkowników, a nie na strukturze istniejących danych w systemach zaplecza. Bezpieczeństwo jest kluczowym elementem projektowania interfejsów API dla zewnętrznych użytkowników. Systemy backendowe tradycyjnie nie są budowane z wystarczająco silnym uwierzytelnianiem, aby można je było udostępniać w sieciach publicznych. Właśnie w takich przypadkach Apigee w połączeniu z rozwiązaniem do zarządzania tożsamościami i dostępem może oferować skuteczne rozwiązania do ochrony przed tym zagrożeniem.

Tutaj należy wziąć pod uwagę kilka ważnych elementów, które zostaną omówione w kolejnych sekcjach:

  • Projektowanie zabezpieczeń: pełne wykorzystanie funkcji Apigee do implementowania wzorów uwierzytelniania.
  • Zarządzanie: zapewnienie spójnego stosowania prawidłowych wzorów uwierzytelniania we wszystkich opublikowanych usługach interfejsu API.
  • Bezpieczeństwo operacyjne: możliwość wykrywania podejrzanego lub nietypowego zachowania oraz prób obejścia lub złamania haseł uwierzytelniających proksy API.

Projektowanie zabezpieczeń

Celem projektu zabezpieczeń jest prawidłowe wdrożenie procesów uwierzytelniania i integracji z zewnętrznymi narzędziami do zarządzania tożsamością. Projektowanie zabezpieczeń to kluczowy etap, który zaczyna się od zrozumienia, jakiego typu przepływ danych w ramach delegowanego uwierzytelniania należy użyć w zależności od typu aplikacji, która będzie korzystać z punktów końcowych interfejsu API. Następnym krokiem jest określenie we współpracy z zespołem ds. tożsamości wzorów integracji, które należy zaimplementować w rozwiązaniu do zarządzania tożsamością.

Specyfikacje RFC OpenID Connect i OAuth zawierają wiele delegowanych przepływów uwierzytelniania i autoryzacji, a także informacje o podmiotach zaangażowanych w te przepływy. To skomplikowany temat, a nieprawidłowe uwierzytelnianie jest jednym z najczęstszych zagrożeń dla interfejsów API według OWASP. Ten dokument nie zawiera kompleksowego wprowadzenia do prawidłowego wdrażania standardów tożsamości, ale Apigee udostępnia wiele dodatkowych materiałów, które pomogą Ci lepiej zrozumieć procesy OAuth, takich jak ten ebook, webcast i przykład implementacji.

Zasady uwierzytelniania

Zasady Apigee, które pomagają rozwiązać problemy z tożsamością i uwierzytelnianiem:

Zarządzanie ruchem

Te funkcje zarządzania ruchem Apigee pomagają chronić przed atakami typu brute force:

  • Zasady Spike Arrest, które służą do ustawienia ogólnego średniego limitu szybkości na serwerze proxy interfejsu API.
  • Zasady dotyczące limitów – umożliwiają szczegółowe ustawianie limitów szybkości dla serwerów proxy interfejsu API na podstawie limitów określonych przez klucze aplikacji, limitów dla deweloperów lub limitów usług interfejsu API.
  • Zasady dotyczące buforowania, które dotyczą buforowania przechowywanych tokenów dostępu na podstawie ich zdefiniowanych czasów ważności, a także możliwość invalidate zaszyfrowanych danych logowania (na przykład w sytuacji, gdy prawidłowy token dostępu został skompromitowany).

Zarządzanie

Zabezpieczenia to ciągły proces, a nie projekt „ustaw i zapomnij”. Jedną z najczęstszych przyczyn naruszeń zabezpieczeń jest nieprawidłowa konfiguracja. Po zdefiniowaniu procesów uwierzytelniania, wzorców integracji tożsamości oraz zasad zarządzania ruchem związanym z uwierzytelnianiem ich prawidłowe i konsekwentne wdrożenie jest kluczowe.

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

Kontrola dostępu oparta na rolach (RBAC)

Niezależnie od tego, czy jesteś właścicielem dużej firmy czy małego startupu, unikanie błędów konfiguracji zaczyna się od zadbania o to, aby tylko odpowiednie osoby i zespoły miały dostęp do konfiguracji serwera proxy API i mogły je modyfikować. Programy interfejsów API są obsługiwane przez interdyscyplinarne zespoły w organizacji. W ramach korzystania z interfejsu API należy każdemu zespołowi przyznać tylko te uprawnienia, które są mu niezbędne do wykonywania zadań.

Apigee udostępnia funkcje, które umożliwiają zarządzanie dostępem na podstawie ról. Dzięki nim możesz przypisywać użytkownikom zdefiniowane wstępnie role lub tworzyć role niestandardowe, które będą odpowiadać potrzebom zespołów API. Prawidłowe zdefiniowanie przypisywania ról i zarządzanie nim jest kluczowe dla bezpiecznego skalowania programu interfejsu API. Możesz też użyć federacji do integracji z dotychczasowym katalogiem korporacyjnym i ograniczenia potrzeby zarządzania drugim zestawem danych logowania administratora w usłudze Apigee.

Przepływy współdzielone

Procesy współdzielone umożliwiają definiowanie zasad i zasobów w obiekcie wielokrotnego użytku, który można stosować w różnych serwerach proxy interfejsu API. Na przykład wspólnie z zespołami ds. bezpieczeństwa możesz opracować wiele wzorów projektowania uwierzytelniania na podstawie typu aplikacji korzystającej z interfejsu API. Deweloper interfejsu API nie musi być ekspertem w zakresie tożsamości, aby móc ponownie użyć tej metody. Wystarczy, że zna odpowiedni przepływ danych, który można dodać do istniejącej konfiguracji serwera proxy interfejsu API za pomocą wywołania przepływu danych.

Rysunek: Shared Flows to wielokrotnie użyte pakiety zasad i reguł warunkowych, które umożliwiają utrzymanie złożonego wzorca.

Raportowanie zabezpieczeń

Gdy już upewnisz się, że tylko odpowiednie osoby w Twojej organizacji mogą modyfikować wzorce uwierzytelniania i zdefiniujesz wspólne przepływy uwierzytelniania, musisz się upewnić, że serwery proxy API opracowane przez zespoły API konsekwentnie stosują te wzorce.

Nowa funkcja Zaawansowane operacje interfejsu API w Apigee obejmuje zaawansowane raportowanie zabezpieczeń, które pozwala zespołom operacji i zabezpieczeń łatwo wyświetlać raporty dotyczące wszystkich proxy interfejsu API. Koncentruje się ona na przestrzeganiu zasad bezpieczeństwa, takich jak korzystanie z wspólnych przepływów. Raportowanie, rejestrowanie i ostrzeganie to kluczowe elementy bezpieczeństwa interfejsu API. Omówimy je dokładniej w sekcji API10: niewystarczające rejestrowanie. Z perspektywy zapobiegania ryzyku związanemu z nieprawidłowym uwierzytelnianiem są one jednak bardzo przydatne, ponieważ zapewniają przestrzeganie zdefiniowanych przez Ciebie standardów uwierzytelniania zaimplementowanych jako wspólne przepływy.

Bezpieczeństwo operacyjne

Gdy interfejsy API są wdrożone w wersji produkcyjnej i korzystają z odpowiednich wzorców uwierzytelniania z wdrożonym zarządzaniem ruchem podstawowym, zespół ds. bezpieczeństwa musi mieć możliwość monitorowania podejrzanych działań i reagowania na nie. Podejrzane działania często zaczynają się od próby przejęcia danych uwierzytelniających.

Apigee Sense

Apigee Sense chroni Twoje interfejsy API przed niechcianym ruchem żądań, w tym atakami ze strony złośliwych klientów. Apigee Sense analizuje ruch związany z żądaniami do interfejsu API, identyfikując wzorce, które mogą odpowiadać niechcianym żądaniom. Dzięki tej analizie możesz zidentyfikować klientów wysyłających niechciane żądania, a potem podjąć działania, aby zezwolić na te żądania, zablokować je lub oznaczyć je jako niechciane. W przyszłości Sense będzie zawierać funkcję automatycznego włączania weryfikacji ReCAPTCHA w przypadku podejrzanego ruchu.

Dzięki Apigee Sense możesz chronić swoje interfejsy API przed wzorcami żądań, które obejmują:

  • Automatyczne działanie, które naśladuje zachowanie człowieka
  • Stale próby z tego samego adresu IP
  • Nietypowe współczynniki błędów
  • Podejrzane żądania klientów
  • indeksowanie danych,
  • Zbieranie kluczy i ataki siłowe uwierzytelniania
  • Przerwy w aktywności
  • wzorce geograficzne.

Zaawansowane operacje na interfejsie API

Sense został zaprojektowany specjalnie do wykrywania zagrożeń związanych z botami i reagowania na nie, ale Advanced API Ops obejmuje zarówno wykrywanie anomalii, jak i definiowanie zaawansowanych alertów.

Wykrywanie anomalii działa dzięki zastosowaniu modeli sztucznej inteligencji (AI) i systemów uczących się (ML) do danych API z przeszłości. Wykrywanie anomalii może następnie wysyłać alerty w czasie rzeczywistym w przypadkach, o których nawet nie pomyślisz, aby zwiększyć produktywność i zredukować średni czas rozwiązania (MTTR) problemów z interfejsem API.

Zaawansowane operacje na interfejsie API korzystają z dotychczasowego mechanizmu alertów monitorowania interfejsu API, aby dodać te zaawansowane typy alertów:

  • Łączna liczba alertów o korkach. Wyświetla alert, gdy ruch zmienia się o określony odsetek w danym zakresie czasowym. Możesz np. ustawić alert, gdy ruch wzrośnie o 5% lub więcej w ciągu godziny albo spadnie o co najmniej 10% w ciągu tygodnia.
  • Alerty o anomaliach. Edge wykrywa problemy z ruchu i wydajnością, dzięki czemu nie musisz ich określać samodzielnie. Możesz wtedy wysłać alert dotyczący tych anomalii.
  • Ostrzeżenia o wygaśnięciu certyfikatu TLS. Wyświetla powiadomienie, gdy kończy się ważność certyfikatu TLS

API3:2019 Zbyt duży wyciek danych

Opis zagrożenia

Opublikowany interfejs API może udostępniać więcej danych niż to konieczne, oczekując, że aplikacja klienta wykona niezbędne filtrowanie. Jeśli atakujący bezpośrednio wysyła zapytanie do interfejsu API, może uzyskać dostęp do danych wrażliwych.

Jedną z zasad projektowania interfejsów API, które są stosowane w Apigee, jest zasada od zewnątrz do wewnątrz, która zakłada oszczędne korzystanie z danych. Współpracuj z projektantami UX i programistami, aby udostępniać dane tylko za pomocą interfejsów API, które są potrzebne w interfejsie aplikacji. Systemy backendowe nie zostały zaprojektowane pod kątem publicznych wzorców użycia, dlatego jednym z pierwszych zadań w ramach podejścia „najpierw interfejs API” z użyciem Apigee jest ograniczenie danych do minimum niezbędnego do zapewnienia klientom i deweloperom wysokiej jakości interfejsu API.

Kolejną zasadą projektowania w Apigee jest możliwość ponownego użycia. Poza kwestiami bezpieczeństwa poleganie na aplikacji do filtrowania danych dostarczanych przez interfejs API wymaga przeniesienia tej logiki filtrowania na każdą platformę, na którą tworzysz aplikację.

Z punktu widzenia bezpieczeństwa to zagrożenie wynika z delegowania egzekwowania autoryzacji do aplikacji, często na platformie lub systemie operacyjnym, nad którym nie masz kontroli. W artykułach API1 i API2 omawiamy już znaczenie prawidłowej implementacji uwierzytelniania i autoryzacji w celu uniknięcia nieuprawnionego dostępu do danych.

W kolejnych sekcjach dowiesz się, jak:

  • przekształcać żądania i odpowiedzi kierowane do usług backendowych, aby zminimalizować narażenie danych;
  • Wdrożenie obsługi błędów, aby zapobiec ujawnieniu przez szczegółowe komunikaty o błędach informacji o poufnym środowisku atakującym usługom backendu.

Przepisywanie odpowiedzi i żądań

Systemy backendowe nie są zwykle przeznaczone do użytku w publicznych aplikacjach ani w niebezpiecznych publicznych sieciach. Apigee Edge zostało zaprojektowane tak, aby umożliwić wdrażanie publicznych usług interfejsu API poprzez ochronę backendów przed nadmiernym ujawnieniem danych.

Aby to osiągnąć, Apigee stosuje 3 kluczowe zasady:

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

Przypisywanie zasad dotyczących wiadomości

Zasada Przypisz wiadomość zmienia lub tworzy nowe wiadomości z prośbami i odpowiedziami podczas przepływu proxy interfejsu API. Zasady te umożliwiają wykonywanie tych czynności związanych z wiadomościami:

  • Dodaj nowe parametry formularza, nagłówki lub parametry zapytania do wiadomości.
  • Kopiowanie istniejących właściwości z jednej wiadomości do drugiej
  • Usuń nagłówki, parametry zapytania, parametry formularza lub ładunki wiadomości z wiadomości.
  • Ustaw wartość istniejących właściwości w wiadomości

Za pomocą funkcji Przypisz wiadomość zwykle dodajesz, zmieniasz lub usuwasz właściwości żądania lub odpowiedzi. Możesz też użyć opcji Przypisz wiadomość, aby utworzyć niestandardową wiadomość z prośbą lub odpowiedzią i przekazać ją do alternatywnego celu, zgodnie z opisem w artykule Tworzenie niestandardowych wiadomości z prośbą.

Złożone przekształcanie za pomocą kodu niestandardowego

W przypadku złożonych reguł przetwarzania i przepisywania danych, których złożoność wykracza poza możliwości reguł polityki przypisywania wiadomości, możesz użyć języków proceduralnych, takich jak JavaScript, Java czy Python. Możesz dodać kod niestandardowy do serwera proxy interfejsu API, a następnie wywołać go z zasad dodanych do przepływu danych przez serwer proxy. Obsługa kodu proceduralnego została zaprojektowana tak, aby ułatwić Ci wdrażanie złożonego przetwarzania zmiennych przepływu, błędów oraz treści żądań i odpowiedzi.

Za pomocą kodu proceduralnego możesz:

  • Tworzenie złożonych wartości treści lub manipulowanie nimi, np. wartościami żądania i odpowiedzi.
  • przekształcać adresy URL, np. maskować docelowy adres URL punktu końcowego;

Apigee Edge zawiera osobne zasady dotyczące obsługiwanych języków: JavaScript, Java i Python.

Obsługa błędów

Apigee umożliwia wykonywanie niestandardowego przetwarzania wyjątków za pomocą zasady typu Raise Fault. Zasada zgłaszania awarii, która jest odmianą zasady przypisywania wiadomości, umożliwia generowanie niestandardowej odpowiedzi na błąd.

Przepływy współdzielone

Wspólne przepływy danych można stosować do wymuszania standaryzacji komunikatów o błędach. Na przykład te same skonfigurowane zasady, które wykrywają określony kod błędu HTTP z backendu, mogą służyć do przekształcania odpowiedzi z błędem w celu zwrócenia ogólnego komunikatu o błędzie.

API4:2019 Brak zasobów i ograniczenie szybkości

Opis zagrożenia

Jeśli nie wdrożysz zasad ograniczania szybkości, atakujący mogą przeciążyć backend atakami typu DoS.

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

  • limity i zasady zapobiegania wzrostom natężenia ruchu jako środki zapobiegawcze do nakładania ograniczeń na żądania interfejsu API przychodzące z zewnątrz.
  • Apigee Sense do dynamicznego wykrywania ataków napędzanych przez boty i reagowania na nie
  • zaawansowane monitorowanie i ostrzeganie interfejsu API jako funkcje wykrywania, które powiadamią o trwających atakach typu DDoS;

Ograniczenie szybkości za pomocą limitów i szczytów Zatrzymanie zasad

Apigee udostępnia 2 zasady ograniczania szybkości:

  • Zatrzymanie wzrostu zapewnia ogólną zasadę zdefiniowaną na poziomie serwera proxy interfejsu API, która ogranicza ogólną liczbę przychodzących żądań do backendu.
  • Limity stanowią szczegółowe narzędzie do egzekwowania zasad dotyczących limitów, zarówno na poziomie serwera proxy interfejsu API, jak i na poziomie usługi interfejsu API.

Spike Arrest

Zasada Spike Arrest chroni przed nagłymi wzrostami liczby wizyt. Ta zasada ogranicza liczbę żądań przetwarzanych przez serwer proxy interfejsu API i wysyłanych do backendu, chroniąc przed opóźnieniami w działaniu i przestojami. Do tego celu wykorzystuje średnią ruchomą, którą można zdefiniować w ramach zasady.

Limity

Zasada limitu umożliwia konfigurowanie liczby wiadomości z żądaniem, na które proxy interfejsu API zezwala w okresie czasu, np. minuty, godziny, dnia, tygodnia lub miesiąca. Możesz ustawić ten sam limit dla wszystkich aplikacji uzyskujących dostęp do proxy API lub ustawić limit na podstawie:

  • Produkt, który zawiera serwer proxy interfejsu API
  • Aplikacja wysyłająca żądanie do interfejsu API
  • Deweloper aplikacji
  • wiele innych kryteriów.

Ta zasada jest bardziej szczegółowa niż zasada zatrzymania wzrostu i zwykle powinna być stosowana równolegle z nią.

Wykrywanie botów za pomocą Apigee Sense

Dzięki Apigee Sense możesz zezwalać na żądania od konkretnych klientów, zakresów adresów IP lub organizacji autonomicznych systemów, blokować je lub oznaczać jako nieprawidłowe na podstawie tych klientów lub lokalizacji wykazujących złośliwe lub podejrzane zachowanie. Apigee Edge stosuje te działania do żądań, zanim przekażą je do obsługi interfejsu API. Na przykład można wykryć zakres adresów IP lub konkretnego klienta, który działa w sposób „złomujący hasło”, a następnie zablokować go lub oznaczyć.

Wykrywanie zagrożeń za pomocą zaawansowanych funkcji API Ops Monitoring

Użyj alertu dotyczącego ruchu, aby wysłać powiadomienie, gdy ruch w środowisku, na serwerze proxy lub w regionie zmieni się o określony odsetek w danym przedziale czasu. Ta funkcja może dynamicznie generować alerty, gdy ruch znacznie odbiega od oczekiwanej przepustowości, co ma miejsce podczas ataku DDoS. Te alerty można łatwo wysyłać do zewnętrznego rozwiązania do rejestrowania i monitorowania.

API5:2019 Nieprawidłowa autoryzacja na poziomie funkcji

Opis zagrożenia

To zagrożenie jest odmianą zagrożenia API1 i także stwarza lukę w zabezpieczeniach związanych z autoryzacją. Dzięki temu zagrożeniu atakujący może wykonywać czynności poprzez wysyłanie żądań do funkcji, do których nie ma uprawnień. Na przykład atakujący może zmodyfikować lub usunąć dane, do których ma tylko uprawnienia do odczytu, jeśli punkt końcowy interfejsu API nie weryfikuje czasownika żądania HTTP, zastępując GET przez PUT lub DELETE. Jeśli nie wdrożysz wystarczająco restrykcyjnej kontroli dostępu do ścieżki URI zasobu interfejsu API, punkt końcowy interfejsu API może pozwolić atakującemu na wyświetlanie danych innego użytkownika po prostu przez zmianę ścieżki w żądaniu.

Ten typ zagrożenia podkreśla wartość korzystania z Apigee jako warstwy pośredniczącej i abstrahującej, ponieważ wiele systemów backendowych, które nie są przeznaczone do publicznego dostępu, 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, które zmniejszają prawdopodobieństwo wystąpienia tego zagrożenia, są zwykle podzielone na:

  • Co jest chronione? Zastanów się nad strategią dotyczącą interfejsu API i wprowadź logiczne podziały funkcji, korzystając z sprawdzonych metod dotyczących interfejsów REST, aby zaprojektować ścieżki i zasoby udostępniane przez interfejsy API, produkty i funkcje aplikacji Apigee.
  • Kto uzyskuje dostęp do Twoich zasobów interfejsu API? Określ ogólne typy użytkowników i wprowadź uprawnienia dostępu domyślnego „najmniejszego uprzywilejowania” za pomocą niektórych funkcji uwierzytelniania i autoryzacji Apigee opisanych w artykułach API1 i API2.
  • Jak są egzekwowane zasady dostępu? Używaj przepływów warunkowych i błędów, aby sprawdzać poprawność ścieżki URL i czasownika wszystkich żądań interfejsu API.

Rysunek: diagram pokazujący, jak w Apigee można wymusić autoryzację na poziomie funkcji, używając zakresów podanych w tokenie dostępu jako uprawnień.

Segmentacja logiczna za pomocą interfejsów API, serwerów proxy, usług i aplikacji

Apigee udostępnia bardzo elastyczny zestaw narzędzi umożliwiający logiczną segmentację zasobów interfejsu API. Dzięki temu pośredniki interfejsu API mogą być pakowane w dowolną liczbę usług API, z których korzystają deweloperzy aplikacji. Mogą oni rejestrować aplikacje korzystające z Twoich usług API. Zasady dostępu można definiować na dowolnym z tych poziomów.

Aby jednak wdrożyć skuteczne uwierzytelnianie i segmentację funkcjonalną, musisz określić strategię dotyczącą usług API. Częścią tego istotnego i ciągłego procesu jest określenie „kto” i „co” w przypadku Twoich produktów interfejsu API. Aby to zrobić, musisz spojrzeć na zasoby interfejsu API z perspektywy klienta i programisty, a potem dokładnie określić, jakie typy żądań będą dozwolone, aż do poziomu ścieżki zasobu i czasownika HTTP.

Rysunek: zasoby interfejsu API zawarte w produkcie interfejsu API mogą pochodzić z jednego lub większej liczby interfejsów API, więc możesz łączyć i dopasowywać zasoby, aby tworzyć poziomy konsumpcji i granice autoryzacji.

Dostęp na poziomie funkcji Kontrola za pomocą zakresów OAuth i zasad JWT

Metody autoryzacji opisane powyżej w API1:2019 Broken object authorization zapewniają szczegółową kontrolę dostępu na poziomie obiektu, ale równie ważne jest zapewnienie ogólnej kontroli dostępu na poziomie funkcji. Czy użytkownik, który wysyła żądanie, ma w ogóle uprawnienia do żądania tej ścieżki adresu URL? Ten typ zasad jest często definiowany w zależności od typu użytkownika (klient, pracownik, administrator, wewnętrzny lub zewnętrzny deweloper).

Aby zmniejszyć ryzyko błędnej konfiguracji, zalecamy współpracę z zespołem ds. bezpieczeństwa, aby upewnić się, że oświadczenia dotyczące użytkownika przesyłającego żądanie są zawarte w tokenie dostępu, albo za pomocą zakresów uprawnień OAuth, albo za pomocą twierdzeń JWT.

Prośba o weryfikację z użyciem przepływów warunkowych

Od podstaw wywołanie interfejsu API REST składa się z tych elementów:

  • Punkt końcowy
  • Zasób
  • czasownik czynnościowy,
  • dowolną liczbę dodatkowych atrybutów żądania, takich jak parametry zapytania;

Typ ataku omówionego w tym zagrożeniu jest zwykle spowodowany niewystarczającym odfiltrowywaniem żądań interfejsu API, co pozwala atakującemu na wykonywanie nieautoryzowanych działań lub uzyskiwanie dostępu do chronionych zasobów. Oprócz logiki warunkowej, która umożliwia filtrowanie żądań na podstawie tokenów dostępu lub twierdzeń, Apigee umożliwia implementowanie logiki filtrowania na podstawie samego żądania.

Gdy już dokładnie zrozumiesz i zdefiniujesz logikę biznesową interfejsu API, a także funkcje dozwolone przez Twoje interfejsy API, możesz zablokować żądania, które nie mieszczą się w tych ramach, za pomocą tych funkcji produktów Apigee:

  • logika warunkowa i zasady Raise Fault, aby ograniczać ścieżki zasobów lub czasowniki na dowolnym etapie konfiguracji przepływu proxy;
  • JSON i XML Zasady ochrony przed zagrożeniami, które chronią przed atakami wykorzystującymi treści w źle sformułowanych ładunkach żądań w formacie JSON lub XML

API6:2019 Mass assignment

Opis zagrożenia

Nieprzefiltrowane dane dostarczane przez interfejsy API do aplikacji klienckich umożliwiają atakującym zgadywanie właściwości obiektów za pomocą żądań lub korzystanie z konwencji nazewnictwa punktów końcowych w celu uzyskania wskazówek, gdzie można dokonać nieautoryzowanej modyfikacji lub uzyskać dostęp do właściwości obiektów danych przechowywanych na zapleczu.

To zagrożenie występuje, gdy do klienta wysyłane są nieprzefiltrowane dane (zwykle w formacie JSON lub XML), co pozwala atakującemu zgadnąć szczegóły implementacji Twoich systemów zaplecznych, a także nazwy właściwości elementów poufnych danych. W efekcie tego typu ataku osoba atakująca może uzyskać możliwość odczytu lub manipulowania nieodpowiednimi danymi, a w najgorszym przypadku może wykorzystać luki umożliwiające zdalne uruchomienie kodu.

Zwykle są 2 aspekty umożliwiające tego typu zagrożenia:

  • Perspektywa projektowania interfejsu API. Nigdy nie polegaj na logice aplikacji do filtrowania danych po stronie klienta, ponieważ aplikacje mogą być wykorzystywane przez osoby atakujące i uważane za zaufane. Zawsze projektuj schemat danych interfejsu API tak, aby udostępniać tylko minimalne dane niezbędne do włączenia usługi interfejsu API.
  • Perspektywa implementacji interfejsu API. Wdróż filtrowanie danych i weryfikację schematu, aby zapobiec przypadkowemu ujawnieniu poufnych danych aplikacji klienta.

W ramach usługi Apigee udostępniamy kilka przydatnych funkcji, które zapewniają solidne filtrowanie danych w Twoich interfejsach API.

Zasady filtrowania specyfikacji OpenAPI

Zasady OASValidation (walidacji specyfikacji OpenAPI) umożliwiają sprawdzanie przychodzących żądań lub odpowiedzi w porównaniu ze specyfikacją OpenAPI 3.0 (w formacie JSON lub YAML). Te zasady umożliwiają:

  1. Zaprojektuj interfejs API, tworząc specyfikację OpenAPI (OAS)
  2. Zaimplementuj niezbędną logikę dotyczącą pośrednictwa, zabezpieczeń i buforowania, aby bezpiecznie udostępniać produkt API z backendu za pomocą Apigee.
  3. Sprawdzanie przychodzących żądań pod kątem zgodności ze schematem danych zdefiniowanym w specyfikacji OAS, w tym ścieżki podstawowej, czasownika, zasad dotyczących wiadomości z żądaniem i parametrów.

Zasady weryfikacji komunikatów SOAP

Zasady walidacji wiadomości SOAP umożliwiają sprawdzanie poprawności żądań opartych na XML poprzez walidację wiadomości XML na podstawie schematu XSD lub walidację wiadomości SOAP na podstawie definicji WSDL. Dodatkowo możesz użyć zasady weryfikacji wiadomości, aby sprawdzić, czy ładunek wiadomości w formacie JSON lub XML jest poprawnie sformatowany. Obejmuje to sprawdzenie w wiadomości w formacie XML lub JSON tych elementów:

  • Jest tylko jeden element główny.
  • Treść nie zawiera niedozwolonych znaków.
  • obiekty i tagi są prawidłowo zagnieżdżone,
  • Tagi początkowy i końcowy są takie same.

API7:2019 Nieprawidłowa konfiguracja zabezpieczeń

Opis zagrożenia

Nieprawidłowa konfiguracja zabezpieczeń jest zwykle wynikiem niepewnych domyślnych konfiguracji, niekompletnych lub ad hoc konfiguracji, otwartego magazynu danych w chmurze, nieprawidłowo skonfigurowanych nagłówków HTTP, niepotrzebnych metod HTTP, zezwalania na współdzielenie zasobów między domenami (CORS) oraz szczegółowych komunikatów o błędach zawierających poufne informacje. Przestępcy często próbują znaleźć niezałatane luki, typowe punkty końcowe lub niezabezpieczone pliki i katalogi, aby uzyskać nieautoryzowany dostęp do systemu lub informacje o nim. Niewłaściwa konfiguracja zabezpieczeń może nie tylko ujawnić poufne dane użytkowników, ale też szczegóły systemu, które mogą doprowadzić do całkowitego skompromitowania serwera. Do innych przypadków użycia luk w zabezpieczeniach związanych z nieprawidłową konfiguracją zabezpieczeń należą:

  • Nieprawidłowo skonfigurowany TLS
  • komunikaty o błędach z zrzutami stosu.
  • Niezałatywane systemy
  • panele zarządzania pamięcią lub serwerem;

Organizacje mogą podjąć różne działania, aby rozwiązać problemy związane z błędami konfiguracji zabezpieczeń i je zminimalizować. Do takich działań należą:

  1. ustanawianie i standaryzowanie procesów wzmacniania i łatania;
  2. opracowywanie zasad dotyczących ekosystemu interfejsów API;
  3. Ograniczanie dostępu administracyjnego oraz włączanie funkcji monitorowania i powiadamiania

Przepływy współdzielone i punkty zaczepienia przepływów

Apigee obsługuje koncepcję wspólnego procesu, która pozwala deweloperom interfejsu API łączyć zasady i zasoby w grupę do wielokrotnego użytku. Dzięki umieszczeniu w jednym miejscu funkcji, które można wielokrotnie wykorzystywać, wspólny przepływ danych pomaga zapewnić spójność, skrócić czas rozwoju i ułatwić zarządzanie kodem. Możesz uwzględnić wspólny przepływ danych w pojedynczych proxy interfejsu API lub pójść o krok dalej i umieścić wspólne przepływy danych w elementach sterujących przepływem danych, aby automatycznie wykonywać logikę wspólnych przepływów danych dla każdego proxy interfejsu API wdrożonego w tym samym środowisku co wspólny przepływ danych.

Raportowanie dotyczące bezpieczeństwa interfejsu API

Organizacje starają się opracować ramy zarządzania, a Apigee udostępnia funkcje raportowania zabezpieczeń interfejsów API, które pomagają zespołom operacyjnym w uzyskiwaniu widoczności niezbędnych atrybutów zabezpieczeń interfejsów API, aby:

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

Raporty Apigee Security dostarczają zespołom operacyjnym szczegółowych informacji, które pomagają im przestrzegać zasad i wymagań dotyczących konfiguracji, chronić interfejsy API przed nadużyciami wewnętrznymi i zewnętrznymi oraz szybko wykrywać i rozwiązywać incydenty związane z bezpieczeństwem.

Dzięki raportom bezpieczeństwa administratorzy mogą szybko sprawdzić, jak skonfigurowane są proxy interfejsu API pod kątem bezpieczeństwa, a także warunki działania, które mogą wpływać na bezpieczeństwo proxy. Dzięki tym informacjom możesz dostosować konfigurację, aby zapewnić odpowiedni poziom zabezpieczeń dla każdego serwera proxy.

Monitorowanie interfejsu API

Apigee udostępnia kompleksową platformę do monitorowania interfejsów API, która uzupełnia funkcje raportowania zagrożeń. Monitorowanie interfejsu API umożliwia organizacjom zapobieganie problemom z ruchu i wydajnością interfejsu API. Monitorowanie interfejsów API Apigee działa w połączeniu z Apigee Edge dla chmury publicznej, aby dostarczać w czasie rzeczywistym kontekstowe informacje o wydajności interfejsów API, pomagać w szybkiej diagnozie problemów i ułatwiać podejmowanie działań naprawczych w celu zapewnienia ciągłości działania firmy.

Rysunek: monitorowanie interfejsu API w usłudze Apigee udostępnia szeroki zakres narzędzi do monitorowania, analizowania i rozwiązywania problemów. Korzysta z najlepszych w swojej klasie funkcji analitycznych Google Cloud Platform.

Apigee Sense

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

Dzięki tej analizie organizacje mogą identyfikować klientów wysyłających niechciane żądania, a potem podejmować działania, aby zezwolić na te żądania, zablokować je lub oznaczyć je jako niechciane. Dzięki Apigee Sense można chronić interfejsy API przed wzorami żądań, które obejmują:

  • Automatyczne działanie, które naśladuje zachowanie człowieka
  • Stale próby z tego samego adresu IP
  • Nietypowe współczynniki błędów
  • Podejrzane żądania klientów
  • indeksowanie danych,
  • Zbieranie kluczy
  • Przerwy w aktywności
  • wzorce geograficzne.

API8:2019 Injection

Opis zagrożenia

Niezaufane wstrzykiwanie danych, takich jak SQL, NoSQL, parsery XML, ORM, LDAP, polecenia systemu operacyjnego i JavaScript, do żądań interfejsu API może spowodować wykonanie niezamierzonych poleceń lub nieautoryzowany dostęp do danych. Atakujący będą podawać interfejsowi API złośliwe dane za pomocą dostępnych wektorów wstrzyknięcia, takich jak bezpośrednie dane wejściowe, parametry, zintegrowane usługi itp., spodziewając się, że zostaną one przesłane do interpretera. Atakujący mogą łatwo wykryć te błędy, gdy sprawdzają kod źródłowy za pomocą skanera luk w zabezpieczeniach i narzędzi fuzzingu. Udane wstrzyknięcie może doprowadzić do ujawnienia informacji, co wpłynie na poufność i utratę danych, a w niektórych przypadkach może też spowodować DoS.

Sprawdzone metody zapobiegania błędom/atakom polegającym na wstrzykiwaniu danych obejmują ścisłe definiowanie danych wejściowych, takich jak schematy, typy i wzorce ciągów znaków, przeprowadzanie weryfikacji danych wejściowych oraz sprawdzanie limitów i wymuszanie ich w czasie wykonywania. Platforma Apigee umożliwia sprawdzanie danych przychodzących za pomocą filtrów, aby zezwalać tylko na prawidłowe wartości dla każdego parametru wejściowego.

Apigee Edge, działając jako serwer dla przychodzących żądań interfejsu API, sprawdza, czy struktura ładunku mieści się w akceptowalnym zakresie, co nazywamy również sprawdzaniem limitu. Możesz skonfigurować serwer proxy dla interfejsu API, tak aby rutyna sprawdzania poprawności danych przekształcała dane wejściowe w celu usuwania niebezpiecznych sekwencji znaków i zastępowania ich bezpiecznymi wartościami.

Zasady ochrony za pomocą wyrażeń regularnych

Zasada RegularExpressionProtection wyodrębnia informacje z wiadomości (np. ścieżkę URI, parametr zapytania, nagłówek, parametr formularza, zmienną, ładunek XML lub ładunek JSON) i porównuje te treści z wstępnie zdefiniowanymi wyrażeniami regularnymi. Jeśli dowolne określone wyrażenia regularne zwrócą wartość true, wiadomość zostanie uznana za zagrożenie i odrzucona. Wyrażenie regularne, w skrócie regex, to zbiór ciągów tekstowych, które określają wzór w ciągu tekstowym. Wyrażenia regularne umożliwiają programowe sprawdzanie treści pod kątem wzorców. Wyrażeń regularnych można używać na przykład do sprawdzania adresu e-mail, aby upewnić się, że jest on prawidłowo sformatowany.

Najczęstszym zastosowaniem reguł RegularExpressionProtection jest sprawdzanie, czy ładunki JSON i XML nie zawierają szkodliwych treści.

Żadne wyrażenie regularne nie może wyeliminować wszystkich ataków opartych na treściach, dlatego należy połączyć kilka mechanizmów, aby zapewnić obronę wielowarstwową. W tej sekcji opisujemy zalecane wzorce zapobiegania dostępowi do treści.

Platforma Apigee umożliwia też inne sposoby sprawdzania danych wejściowych:

Sprawdzanie typów treści

Typ treści odnosi się do treści pliku, który jest przesyłany przez HTTP i klasyfikowany według dwuczęściowej struktury. Apigee zaleca sprawdzanie typów treści żądania i odpowiedzi za pomocą logiki warunkowej opisanej poniżej.

Raportowanie dotyczące bezpieczeństwa interfejsu API

Organizacje starają się opracować ramy zarządzania, a Apigee udostępnia funkcje związane z raportowaniem o bezpieczeństwie interfejsów API, które pomagają zespołom operacyjnym i zapewniają im widoczność niezbędną do zabezpieczenia interfejsów API. Dzięki temu zespoły operacyjne mogą korzystać z właściwych atrybutów zabezpieczeń interfejsów API, aby:

  • Zadbaj o to, aby przestrzegać zasad bezpieczeństwa i wymagań dotyczących 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.

API9:2019 Nieprawidłowe zarządzanie komponentami

Opis zagrożenia

Niewystarczające zarządzanie środowiskiem i segregacja środowisk umożliwiają atakującym dostęp do punktów końcowych interfejsu API o niskiej ochronie. Brak środków kontroli może też powodować niepotrzebne narażenie zasobów wycofanych.

Zagrożenie to można wyeliminować, korzystając z doświadczenia firmy Apigee w zakresie zarządzania całym cyklem życia interfejsu API. Dzięki temu możesz tworzyć kompleksowy model zarządzania, który umożliwia współpracę między zespołami, a zarazem umożliwia rozdzielenie obowiązków między interesariuszami ds. bezpieczeństwa a programistami interfejsów API. Granice i elementy sterujące można konfigurować i utrzymywać za pomocą:

Organizacje, środowiska i wersje: wirtualne i fizyczne zabezpieczenia, które gwarantują izolację i zabezpieczony proces promowania za pomocą kontekstów w czasie wykonywania.

Zarządzanie dostępem na podstawie ról: tylko niezbędne osoby w zespołach interfejsu API będą miały uprawnienia do zarządzania zmianami konfiguracji oraz 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 odbiorcami docelowymi.

Elementy przepływu: możesz wymuszać stosowanie globalnych zasad i wzorców, którymi można zarządzać jako uprzywilejowanymi barierami ochronnymi, których deweloperzy interfejsu API nie mogą modyfikować.

Raportowanie zabezpieczeń: osoby odpowiedzialne za bezpieczeństwo mają pełną widoczność opublikowanych interfejsów API i ich konfiguracji. Zgodność z globalnymi zasadami bezpieczeństwa można sprawdzić i ocenić na podstawie profilu ryzyka każdego opublikowanego punktu końcowego interfejsu API.

Organizacje i środowiska

Elementy konfiguracji, użytkownicy i funkcje w Apigee mogą być ograniczone do określonych organizacji lub środowisk. Oznacza to, że platforma ma wbudowane zabezpieczenia, które można ustawić wokół interfejsów API i ich konfiguracji pomocniczej.

Organizacje: organizacja to najemca najwyższego poziomu w Apigee. Umożliwia to pełną segregację ruchu, konfiguracji i użytkowników. Zgodnie ze sprawdzoną metodą należy prowadzić oddzielne organizacje produkcyjne i nieprodukcyjne. Dzięki temu można skutecznie uniknąć mieszania danych produkcyjnych, użytkowników i ruchu z niższymi środowiskami.

Środowiska: interfejsy API w usłudze Apigee można promować w różnych stanach wdrożenia. Każdy stan jest powiązany z kontekstem wykonania. W trakcie procesu promowania nie jest uwzględniany kontekst środowiska, dzięki czemu nie ma ryzyka ujawnienia poufnej konfiguracji użytkownikom bez uprawnień.

Zmiany: zmiany umożliwiają płynne promowanie interfejsów API i poszczególnych funkcji w różnych środowiskach.

Kontrola dostępu oparta na rolach

Aby ograniczyć ryzyko związane z API9, należy wyraźnie określić obowiązki osób odpowiedzialnych za bezpieczeństwo i deweloperów interfejsu API oraz rozdzielić je. Jak już wspomnieliśmy w tym dokumencie, Apigee oferuje elastyczne funkcje kontroli dostępu na podstawie ról, które umożliwiają przypisywanie uprawnień do ról niestandardowych. W przypadku tego konkretnego zagrożenia role mogą mieć ograniczone uprawnienia w poszczególnych organizacjach, środowiskach lub bardziej szczegółowych uprawnieniach konfiguracyjnych. Zalecamy ograniczenie uprawnień do zmiany stanu wdrożenia interfejsów API w różnych środowiskach, a także dopilnowanie, aby deweloperzy nie mieli dostępu do globalnych bibliotek zabezpieczeń ani możliwości ich modyfikowania (zaczepy przepływu). Te ograniczone role uniemożliwiają nieautoryzowane zmiany w globalnych zasadach bezpieczeństwa, które mają szeroki zakres zarówno w przypadku starszych, jak i opublikowanych obecnie punktów końcowych.

Zarządzanie odbiorcami w dokumentacji interfejsu API

Portal dla deweloperów to kluczowy element strategii dotyczącej interfejsów API. Pozwala on prowadzić kompleksowy katalog całej dokumentacji dotyczącej interfejsów API, w tym hostów/punktów końcowych, zasobów, operacji, schematów ładunku i innych elementów. W Apigee możesz grupować interfejsy API za pomocą konstrukcji Produktu interfejsu API. Produkty interfejsu API są definiowane przez pakiety zasobów i operacji, które mieszczą się w tym samym kontekście biznesowym i bezpieczeństwa (np. plan usługi, domena biznesowa, kategoria, hierarchia firmy itp.).

Dzięki zintegrowanemu portalowi deweloperów w usłudze Apigee możesz publikować produkty interfejsu API i ograniczać widoczność opublikowanych treści, zarządzając grupami odbiorców docelowych. Ta funkcja jest zgodna ze strategią podziału treści na segmenty, która jest dostosowana do potrzeb biznesowych i wymagań bezpieczeństwa.

Elementy sterujące przepływem

Procesy promowania i publikowania interfejsów API muszą zawsze obejmować procesy certyfikacji i sprawdzania zgodności z zasadami bezpieczeństwa. Aby być skuteczne, zespoły API korzystające z odpowiednich narzędzi powinny mieć możliwość tworzenia zabezpieczeń, które gwarantują rozdzielenie odpowiedzialności przy jednoczesnym zachowaniu zwinnych cykli wdrożeniowych.

Apigee umożliwia Ci podniesienie poziomu zadań związanych z zarządzaniem bezpieczeństwem przez wymuszanie zasad globalnych za pomocą haków przepływu. Tymi globalnymi zasadami można zarządzać jako uprzywilejowanymi barierami, których deweloperzy interfejsu API nie mogą modyfikować. Gwarantuje to rozdzielenie odpowiedzialności i zwiększa elastyczność dzięki zastosowaniu domyślnych zabezpieczeń, a co za tym idzie, zapewnia zgodność ze standardami bezpieczeństwa we wszystkich interfejsach API wdrożonych w danym środowisku wykonania.

Rysunek: bariery ochronne z przywilejami można konfigurować w Apigee za pomocą elementów sterujących przepływem i wspólnych przepływów. Za utrzymanie globalnych zasad dotyczących bezpieczeństwa odpowiadają osoby odpowiedzialne za bezpieczeństwo. Te funkcje gwarantują rozdzielenie odpowiedzialności i promują cykle programowania zgodne z zasadami zwinnego rozwoju.

Raportowanie zabezpieczeń

Audyt bezpieczeństwa ma na celu ocenę i sprawdzenie zasad bezpieczeństwa, które mają chronić dane i cele biznesowe Twojej organizacji. Interfejsy API to standaryzowane publiczne lub prywatne interfejsy, które muszą być chronione za pomocą kompleksowego i jednocześnie poddanego audytowi modelu zarządzania bezpieczeństwem.

W Apigee masz dostęp do specjalistycznych raportów bezpieczeństwa, które pomagają zapewnić zgodność z określonymi zasadami i umożliwiają zespołom ds. bezpieczeństwa podejmowanie działań na podstawie kompleksowych informacji o:

Czas wykonywania: w tym widoku znajdziesz informacje o ruchu w interfejsach API dotyczące serwerów docelowych, hostów wirtualnych, konfiguracji TLS, zmian ruchu w poszczególnych środowiskach i wiele innych.

Konfiguracja: funkcja sprawdzania konfiguracji serwerów proxy interfejsu API, która zapewnia pełną przejrzystość wszystkich zasad stosowanych na poziomie serwera proxy interfejsu API, a także zakresu stosowania wspólnych przepływów danych dołączonych na poziomie organizacji lub serwera proxy.

Aktywność użytkownika: umożliwia śledzenie operacji wrażliwych wykonywanych przez użytkowników platformy. Analizuj podejrzaną aktywność, korzystając z funkcji szczegółowego wyświetlania podejrzanej aktywności.

API10:2019 Niewystarczające logowanie i monitorowanie

Opis zagrożenia

Niewystarczające rejestrowanie, monitorowanie i ostrzeganie umożliwiają niezauważenie trwających ataków, dlatego należy opracować strategię, która pozwoli uzyskać informacje o krytycznych zdarzeniach wpływających na Twoją firmę.

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

  • Zasady zarządzania logami: dokumentowanie i egzekwowanie reguł w celu standaryzacji i kontrolowania szczegółowości logów, poziomów logów, integralności logów, scentralizowanego repozytorium i innych kwestii.
  • Zasady zarządzania zdarzeniami: gwarancja, że każde zdarzenie można prześledzić do jego źródła. Poza tym zdarzenia powinny być możliwe do pogrupowania według ich wagi i wpływu na działalność firmy.
  • Raporty i kontrole: osoby odpowiedzialne za bezpieczeństwo i operacje powinny mieć możliwość uzyskiwania dostępu do dzienników i zdarzeń w czasie rzeczywistym oraz reagowania na nie. Dodatkowo zainteresowane strony mogą przeprowadzać cykle wzmacniania, aby dostosowywać wzorce wykrywania na podstawie danych historycznych.

Apigee udostępnia niezbędne narzędzia do tworzenia kompleksowej strategii zarządzania zdarzeniami i rejestrowaniem. Te narzędzia obejmują:

Polityka rejestrowania wiadomości: twórz strumienie logów na podstawie danych o ruchu lub metadanych z ruchu w interfejsie API. Możesz elastycznie określać szczegółowość strumienia, korzystając z logiki warunkowej i szablonów wiadomości.

Pakiet Google Cloud Operations: korzystaj z gotowej integracji z wysoce skalowalnymi narzędziami do monitorowania i rejestrowania Google.

Zasady dotyczące powiadamiania o usługach: dodaje obsługę strumieni logów, które wymagają punktów końcowych HTTP do wysyłania zdarzeń.

Analytics: uzyskuj dostęp do historycznych metadanych ruchu i je analizuj za pomocą domyślnych lub niestandardowych raportów. Tworzenie alertów na podstawie trendów i zarządzanie nimi oraz analizowanie nieprawidłowości w ruchu.

Monitorowanie interfejsu API: jak już wspomnieliśmy, to narzędzie umożliwia tworzenie alertów, które mogą być uruchamiane w przypadku krytycznych zdarzeń. Logi ruchu można analizować i wykorzystywać do dalszych działań.