10 największych zagrożeń interfejsu OWASP API

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

W tym dokumencie opisujemy różne podejścia, które możesz zastosować w Apigee, aby wyeliminować luki w zabezpieczeniach zidentyfikowane przez OWASP. Dodatkowe podejścia udokumentowane w przypadku Apigee znajdziesz w artykule Możliwości łagodzenia zagrożeń z listy OWASP Top 10 2021 w Google Cloud.

Wprowadzenie

OWASP to otwarta społeczność, która pomaga organizacjom tworzyć, kupować i utrzymywać zaufane aplikacje oraz interfejsy API. W ramach projektu OWASP API Security organizacja OWASP publikuje najbardziej krytyczne zagrożenia dla bezpieczeństwa aplikacji internetowych i interfejsów API REST oraz podaje zalecenia dotyczące radzenia sobie z tymi zagrożeniami.

W tym dokumencie omówimy metody ochrony przed typowymi atakami opartymi na interfejsach API, które zostały zidentyfikowane przez OWASP jako 10 największych zagrożeń dla bezpieczeństwa interfejsów API w 2019 roku. Wśród najpoważniejszych zagrożeń wymienionych na najnowszej liście często pojawiają się te, które są spowodowane nieprawidłowym umieszczeniem mechanizmów uwierzytelniania i autoryzacji, np. poleganiem na filtrowaniu danych zwracanych przez żądanie do interfejsu API w aplikacjach klienckich, przez stosowanie antypatternu polegającego na tym, że aplikacja kliencka wykonuje egzekwowanie kontroli dostępu.

Ekosystem interfejsów API rozwija się w szybkim tempie, a nadużycia i nieprawidłowe wykorzystanie interfejsów API, które prowadzą do wycieku danych przez atakujących, stają się obecnie jednym z najczęstszych wektorów ataku. Bezpieczeństwo nadal jest dla Apigee priorytetem. Wprowadziliśmy szereg nowych funkcji, takich jak Advanced API Ops, która obejmuje funkcje 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 należy traktować jako niezaufane lub „publiczne”, ponieważ nie masz kontroli nad platformą, na której działają. Załóż, że każda aplikacja publiczna może zostać naruszona i zostanie naruszona, dlatego nie można jej ufać w zakresie egzekwowania kontroli dostępu (API1, API5), filtrowania danych odpowiedzi (API6) ani bezpiecznego przechowywania kluczy tajnych klienta (API2), takich jak klucze interfejsu API czy tokeny dostępu. Niektóre rekomendacje wynikają z analizy 10 najczęstszych zagrożeń OWASP z 2019 roku:

  • Określ, jakie aplikacje klienckie będą korzystać z Twoich interfejsów API (SPA, mobilne czy oparte na przeglądarce), i zaprojektuj odpowiednie wzorce uwierzytelniania, autoryzacji i zabezpieczeń.
  • Zawsze używaj protokołów OAuth lub OpenID Connect dla „klienta publicznego” (zdecydowanie zalecamy używanie PKCE).
  • Zastanów się nad logiką biznesową aplikacji, najpierw zdefiniuj specyfikację OpenAPI i zaprojektuj serwery proxy interfejsu API, aby filtrować wszystkie dane odpowiedzi z backendu w Apigee. Nigdy nie polegaj na logice kodu aplikacji podrzędnej, aby to zrobić.
  • 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 żądanie.

API1:2019 Uszkodzone uprawnienia na poziomie obiektu

Opis zagrożenia

Niewystarczająca weryfikacja autoryzacji żądania dostępu do obiektu umożliwia atakującemu wykonanie nieautoryzowanego działania przez ponowne użycie tokena dostępu. To zagrożenie jest spowodowane nieprawidłową konfiguracją weryfikacji autoryzacji. Apigee udostępnia zasady VerifyApiKey, protokół OAuth i JSON Web Token (JWT), które pomagają chronić przed tą luką w zabezpieczeniach. Jednak aby zapobiec temu zagrożeniu, konieczne jest prawidłowe skonfigurowanie tych zasad.

Aby zapobiec temu zagrożeniu, zespoły ds. bezpieczeństwa i zespoły deweloperów aplikacji muszą ściśle ze sobą współpracować. Autoryzacja jest z natury złożonym zagadnieniem, a skuteczna szczegółowa autoryzacja wymaga dogłębnego zrozumienia logiki biznesowej aplikacji.

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

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

Integralność tokena dostępu

Konieczne jest sprawdzenie, czy token dostarczony przez klienta wysył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 weryfikacji lub podpisywania danych logowania. Apigee obsługuje wszystkie najczęściej używane przepływy OAuth.

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

Wymuszanie kontroli dostępu

Po zweryfikowaniu ważności tokena dostępu konieczne jest wdrożenie zasad wymuszania kontroli dostępu, aby oceniać każde przychodzące żądanie do interfejsu API pod kątem uprawnień dostępu tokena autoryzacji.

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

  • Wewnętrzne: używanie przepływów warunkowych do oceny próśb o dostęp na podstawie roszczeń wyodrębnionych jako zmienne przepływu z tokena autoryzacji.
  • Delegowane: korzystanie z wywołania usługi w zewnętrznym rozwiązaniu do zarządzania dostępem.

Podejście wewnętrzne (zilustrowane na powyższym rysunku) jest zalecane, gdy model kontroli dostępu jest stosunkowo prosty. Na przykład, jeśli roszczenia wyodrębnione z tokena dostępu mogą być używane do bezpośredniej oceny i autoryzacji żądania obiektu interfejsu API.

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

Podejście delegowane (zilustrowane na powyższym rysunku) jest zalecane, gdy deklaracje wyodrębnione z tokena dostępu nie mogą być bezpośrednio używane do autoryzowania żądania do interfejsu API wysyłanego do obiektu backendu lub w przypadku bardziej złożonych typów przepływu protokołu OAuth, które wymagają oddzielnego wywołania serwera autoryzacji w celu uzyskania tokena dostępu.

Zgodnie z zasadami wywołania usługi można poprosić usługę innej firmy o podjęcie decyzji dotyczącej zasad autoryzacji lub uzyskać dodatkowe informacje o żądającym agencie, a następnie podjąć decyzję o kontroli dostępu za pomocą przepływu warunkowego.

API2:2019 Nieprawidłowe uwierzytelnianie użytkowników

Opis zagrożenia

Źle wdrożone zasady uwierzytelniania użytkowników umożliwiają atakującym podszywanie się pod prawowitych użytkowników poprzez wykorzystywanie błędów w implementacji uwierzytelniania. Podczas wdrażania metod uwierzytelniania warto pamiętać o tych zasadach:

  • Zawsze uwierzytelniaj zarówno klienta użytkownika (aplikację), jak i użytkownika wysyłającego prośbę.
  • Używaj wzorców delegowanego uwierzytelniania i autoryzacji oraz unikaj bezpośredniego przekazywania haseł w żądaniu do interfejsu API.
  • Zawsze sprawdzaj podpis danych logowania i upewnij się, że wszystkie używane dane logowania mają określony czas wygaśnięcia.
  • Zapobiegaj atakom typu brute force, ustawiając limity i używając Apigee Sense do wykrywania ataków typu brute force przeprowadzanych przez boty i reagowania na nie.

W paradygmacie od zewnątrz do wewnątrz projekt interfejsu API jest oparty na przypadkach użycia danych przez konsumentów, a nie na strukturze istniejących danych w systemach backendu. Bezpieczeństwo jest kluczowym elementem podczas projektowania interfejsów API dla konsumentów zewnętrznych. Systemy backendowe tradycyjnie nie są tworzone z wystarczająco silnymi implementacjami uwierzytelniania, które umożliwiają udostępnianie ich w sieciach publicznych. W tym przypadku Apigee w połączeniu z rozwiązaniem do zarządzania tożsamością i dostępem może zapewnić skuteczną ochronę przed tym zagrożeniem.

W tym przypadku należy wziąć pod uwagę kilka ważnych elementów, które omówimy w kolejnych sekcjach:

  • Projektowanie zabezpieczeń: pełne wykorzystanie funkcji Apigee do implementowania wzorców uwierzytelniania.
  • Zarządzanie: zapewnienie, że prawidłowe wzorce uwierzytelniania są używane spójnie we wszystkich opublikowanych produktach API.
  • Bezpieczeństwo operacyjne: możliwość wykrywania podejrzanych lub nietypowych zachowań oraz prób obejścia lub wymuszenia dostępu do uwierzytelnionych proxy interfejsów API.

Projektowanie zabezpieczeń

Celem projektowania zabezpieczeń jest prawidłowe wdrożenie przepływów uwierzytelniania i integracji z narzędziami do zarządzania tożsamością innych firm. Projektowanie zabezpieczeń to kluczowy etap, który rozpoczyna się od określenia odpowiedniego typu przepływu uwierzytelniania delegowanego na podstawie typu aplikacji, która będzie korzystać z punktów końcowych interfejsu API. Następnym krokiem jest zdefiniowanie wraz z zespołem ds. tożsamości wzorców integracji, które mają być wdrożone w rozwiązaniu do zarządzania tożsamością.

Specyfikacje RFC OpenID Connect i OAuth zawierają wiele przepływów delegowanego uwierzytelniania i autoryzacji, a także podmiotów biorących w nich udział. To złożony temat, więc nie dziwi, że nieprawidłowe uwierzytelnianie jest jednym z największych 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 ma wiele dodatkowych materiałów, które pomogą Ci lepiej zrozumieć przepływy OAuth, np. ten e-book i ten webinar oraz przykładowe wdrożenie.

Zasady uwierzytelniania

Zasady Apigee, które pomagają rozwiązywać problemy związane z tożsamością i uwierzytelnianiem, to m.in.:

Zarządzanie ruchem

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

  • Zasady Spike Arrest do ustawiania ogólnego limitu liczby żądań w interfejsie API proxy
  • Zasady dotyczące limitów, które umożliwiają ustawianie precyzyjnych limitów szybkości dla serwerów proxy interfejsu API na podstawie limitów zdefiniowanych przez klucze aplikacji, deweloperów lub limitów usługi API.
  • zasady buforowania, które umożliwiają buforowanie przechowywanych tokenów dostępu na podstawie zdefiniowanych czasów wygaśnięcia, a także unieważnianie buforowanych danych logowania (np. w sytuacji, gdy prawidłowy token dostępu zostanie przejęty przez nieuprawnioną osobę);

Zarządzanie

Bezpieczeństwo to proces ciągły, a nie projekt, który można „ustawić i o nim zapomnieć”. Jedną z najczęstszych przyczyn naruszeń bezpieczeństwa 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 niezwykle ważne jest, aby zostały one wdrożone prawidłowo i spójnie.

Apigee udostępnia wiele funkcji i narzędzi, które zapewniają integralność wdrożenia 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, aby uniknąć błędów konfiguracji, musisz zadbać o to, aby tylko odpowiednie osoby i zespoły miały dostęp do konfiguracji serwera proxy interfejsu API i mogły je modyfikować. Programy API są obsługiwane przez interdyscyplinarne zespoły w całej organizacji. Jest to absolutnie niezbędne, aby każdy zespół miał tylko uprawnienia potrzebne do wykonywania swoich zadań w ramach procesu korzystania z interfejsu API.

Apigee udostępnia funkcje zarządzania dostępem opartym na rolach, które umożliwiają przypisywanie użytkowników do predefiniowanych ról lub tworzenie ról niestandardowych dostosowanych do potrzeb zespołów API. Prawidłowe definiowanie ról i zarządzanie nimi ma kluczowe znaczenie dla bezpiecznego skalowania programu interfejsów API. Możesz też użyć federacji, aby zintegrować Apigee z istniejącym katalogiem firmowym i zmniejszyć potrzebę zarządzania drugim zestawem danych logowania administratora w Apigee.

Przepływy współdzielone

Przepływy współdzielone umożliwiają definiowanie zasad i zasobów w postaci obiektu wielokrotnego użytku, który można wdrażać w proxy interfejsów API. Możesz na przykład wspólnie z zespołami ds. bezpieczeństwa opracować kilka wzorców uwierzytelniania na podstawie typu aplikacji korzystającej z interfejsu API. Programista interfejsu API nie musi być ekspertem w dziedzinie tożsamości, aby ponownie użyć tego przepływu. Wystarczy, że zna prawidłowy przepływ udostępniony, który należy dodać do istniejącej konfiguracji serwera proxy interfejsu API za pomocą zasady wywołania przepływu.

Rysunek: przepływy udostępnione to pakiety zasad i logiki warunkowej, których można używać wielokrotnie, co pozwala zachować złożony wzorzec.

Bezpieczeństwo operacyjne

Gdy interfejsy API są już w produkcji i korzystają z odpowiednich wzorców uwierzytelniania z podstawowym zarządzaniem ruchem, zespół ds. obsługi zabezpieczeń musi też monitorować podejrzaną aktywność i na nią reagować. Często zaczynają się one od prób naruszenia danych uwierzytelniających.

Apigee Sense

Apigee Sense 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 interfejsu API, identyfikując wzorce, które mogą reprezentować niechciane żądania. Na podstawie tej analizy możesz zidentyfikować klientów wysyłających niechciane żądania, a następnie zezwolić na te żądania, zablokować je lub oznaczyć. Przyszłe funkcje Sense będą obejmować możliwość automatycznego włączania weryfikacji reCAPTCHA w przypadku podejrzanego ruchu.

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

  • Automatyczne zachowania, które są podobne do zachowań ludzi
  • Ciągłe próby z tego samego adresu IP
  • Nietypowe odsetki błędów
  • Podejrzane żądania klienta
  • Indeksowanie danych
  • Zbieranie kluczy i ataki siłowe na uwierzytelnianie
  • Nagłe wzrosty aktywności
  • Wzorce geograficzne

Advanced API Ops

Sense został zaprojektowany specjalnie do wykrywania zagrożeń przypominających boty i reagowania na nie, ale Zaawansowane operacje API obejmują zarówno wykrywanie anomalii, jak i zaawansowane definiowanie alertów.

Wykrywanie anomalii działa poprzez stosowanie modeli sztucznej inteligencji (AI) i uczenia maszynowego (ML) do historycznych danych interfejsu API. Wykrywanie anomalii może następnie generować alerty w czasie rzeczywistym w przypadku scenariuszy, o których nawet nie pomyślałeś(-aś), aby zwiększyć produktywność i skrócić średni czas do rozwiązania problemu (MTTR) z interfejsem API.

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

  • Alerty o anomaliach Edge wykrywa problemy z ruchem i wydajnością, więc nie musisz ich samodzielnie określać. Następnie możesz utworzyć alert dotyczący tych anomalii.
  • Alerty o wygaśnięciu TLS. Wysyła powiadomienie, gdy certyfikat TLS zbliża się do daty wygaśnięcia.

API3:2019 Nadmierne ujawnianie danych

Opis zagrożenia

Opublikowany interfejs API może udostępniać więcej danych niż jest to konieczne, polegając na aplikacji klienta w zakresie niezbędnego filtrowania. Jeśli osoba przeprowadzająca atak wyśle zapytanie bezpośrednio do interfejsu API, będzie mogła uzyskać dostęp do danych wrażliwych.

Jedną z zasad projektowania interfejsów API „od zewnątrz” w Apigee jest oszczędność danych. Współpracuj z projektantami UX i programistami, aby udostępniać w interfejsach API tylko te dane, które są potrzebne w interfejsie aplikacji. Systemy backendowe nie zostały zaprojektowane z myślą o publicznych wzorcach użycia, dlatego jednym z pierwszych zadań projektowania interfejsu API w pierwszej kolejności za pomocą Apigee jest ograniczenie danych udostępnianych do minimum niezbędnego do zapewnienia klientom i deweloperom doskonałej usługi interfejsu API.

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

Z punktu widzenia bezpieczeństwa to zagrożenie wynika z przekazania egzekwowania autoryzacji aplikacji, często jednak na platformie lub w systemie operacyjnym, nad którym nie masz kontroli. W API1 i API2 omówiliśmy już, jak ważne jest prawidłowe wdrożenie uwierzytelniania i autoryzacji, aby uniknąć nieuprawnionego dostępu do danych.

W kolejnych sekcjach dowiesz się, jak:

  • Przekształcanie żądań i odpowiedzi do usług backendu w celu zminimalizowania narażenia danych
  • Wdrożenie obsługi błędów, aby zapobiec ujawnianiu przez szczegółowe komunikaty o błędach poufnych informacji o środowisku atakującym na temat usług backendu

Przeredagowywanie odpowiedzi i próśb

Systemy backendowe nie są zwykle przeznaczone do użytku w aplikacjach publicznych ani w niezaufanych sieciach publicznych. Apigee Edge został zaprojektowany tak, aby umożliwiać wdrażanie publicznych interfejsów API poprzez ochronę backendów przed nadmiernym ujawnianiem danych.

W tym celu Apigee korzysta z 3 kluczowych zasad:

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

Przypisywanie zasad dotyczących wiadomości

Zasada Assign Message zmienia lub tworzy nowe wiadomości z prośbą i odpowiedzią podczas przepływu proxy interfejsu API. Zasady umożliwiają wykonywanie tych działań w przypadku takich wiadomości:

  • Dodawanie nowych parametrów formularza, nagłówków lub parametrów 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.
  • Ustawianie wartości istniejących właściwości w wiadomości

Za pomocą zasady Assign Message możesz zwykle dodawać, zmieniać lub usuwać właściwości żądania lub odpowiedzi. Możesz też użyć funkcji Przypisz wiadomość, aby utworzyć niestandardową wiadomość z prośbą lub odpowiedzią i przekazać ją do innego miejsca docelowego, jak opisano w sekcji Tworzenie niestandardowych wiadomości z prośbą.

Złożone przepisywanie za pomocą kodu niestandardowego

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żywać języków proceduralnych, takich jak JavaScript, Java lub Python. Możesz dodać niestandardowy kod do proxy interfejsu API, a następnie wywołać go z zasad dodanych do przepływu proxy. Obsługa kodu proceduralnego ma ułatwić wdrażanie złożonej obsługi 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, takich jak wartości żądań i odpowiedzi, oraz manipulowanie nimi.
  • Przepisywanie adresów URL, np. w celu zamaskowania docelowego adresu URL punktu końcowego.

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

Obsługa błędów

Apigee umożliwia niestandardową obsługę wyjątków za pomocą zasady typu Raise Fault (Zgłoś błąd). Zasada Raise Fault, która jest odmianą zasady Assign Message, umożliwia generowanie niestandardowej odpowiedzi na błąd w reakcji na warunek błędu.

Przepływy współdzielone

Udostępnione automatyzacje mogą służyć do wymuszania standardowych komunikatów o błędach. Na przykład te same skonfigurowane zasady, które wykrywają określony kod błędu HTTP z backendu, mogą być używane do zastępowania odpowiedzi o błędzie ogólnym komunikatem o błędzie.

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

Opis zagrożenia

Jeśli nie wdrożysz zasad ograniczania liczby żądań, atakujący mogą przeciążyć backend atakami typu odmowa usługi.

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

  • Zasady dotyczące limitów i ochrony przed nagłymi wzrostami natężenia ruchu jako środki zapobiegawcze, które ograniczają ruch przychodzących żądań interfejsu API.
  • Apigee Sense do dynamicznego wykrywania ataków botów i reagowania na nie.
  • Zaawansowane monitorowanie interfejsów API i alerty jako mechanizmy kontroli wykrywczej, które informują o trwających atakach typu DDoS.

Ograniczanie liczby żądań za pomocą zasad dotyczących limitów przydziału i nagłych wzrostów

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

  • Ochrona przed nagłymi wzrostami zapewnia ogólną zasadę zdefiniowaną na poziomie serwera proxy interfejsu API, która ogranicza ogólną liczbę żądań przychodzących do backendu.
  • Limity to szczegółowe narzędzie do egzekwowania zasad dotyczących limitów na poziomie serwera proxy interfejsu API lub usługi API.

Spike Arrest

Zasada Spike Arrest chroni przed nagłymi wzrostami ruchu. Ta zasada ogranicza liczbę żądań przetwarzanych przez proxy interfejsu API i wysyłanych do backendu, chroniąc przed opóźnieniami i czasem przestoju. Wykorzystuje ona wartość średniej kroczącej, którą można zdefiniować w zasadach.

Limity

Zasada Quota umożliwia skonfigurowanie liczby komunikatów z żądaniami, na które zezwala serwer proxy interfejsu API w określonym czasie, np. w ciągu minuty, godziny, dnia, tygodnia lub miesiąca. Możesz ustawić ten sam limit dla wszystkich aplikacji uzyskujących dostęp do serwera proxy interfejsu API lub ustawić limit na podstawie:

  • Usługa zawierająca serwer proxy interfejsu API
  • aplikacja, która wysyła żądanie do interfejsu API.
  • Deweloper aplikacji
  • wiele innych kryteriów.

Ta zasada jest bardziej szczegółowa niż ochrona przed nagłymi wzrostami i zwykle powinna być stosowana równocześnie z nią.

Wykrywanie botów za pomocą Apigee Sense

Dzięki Apigee Sense możesz podejmować działania, aby wyraźnie zezwalać na żądania od określonych klientów, zakresów adresów IP lub organizacji systemów autonomicznych, odrzucać je lub oznaczać. Działania te są podejmowane na podstawie tego, czy klienci lub lokalizacje wykazują złośliwe lub podejrzane zachowania. Apigee Edge stosuje te działania do żądań, zanim przetworzą je proxy interfejsów API. Można na przykład wykryć zakres adresów IP lub konkretnego klienta, który wykazuje zachowanie „brute guessor”, a następnie zablokować go lub oznaczyć.

Wykrywanie zagrożeń za pomocą zaawansowanych operacji na interfejsach API Monitorowanie

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

API5:2019 Nieprawidłowe uprawnienia na poziomie funkcji

Opis zagrożenia

To zagrożenie jest odmianą API1 i również stanowi lukę w autoryzacji. W przypadku tego zagrożenia osoba atakująca może wykonywać działania, wysyłając żądania do funkcji, do których nie ma uprawnień dostępu. Na przykład atakujący może modyfikować lub usuwać 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 żądaniem 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 umożliwić atakującemu wyświetlenie danych innego użytkownika przez zwykłą zmianę ścieżki w żądaniu.

Ten rodzaj zagrożenia podkreśla wartość korzystania z Apigee jako warstwy mediacji i abstrakcji, ponieważ wiele systemów backendowych – nieprzeznaczonych do dostępu publicznego – może domyślnie udostępniać jeden punkt końcowy do wykonywania wielu funkcji logiki biznesowej, w tym nawet funkcji administracyjnych wysokiego ryzyka.

Elementy koncepcyjne, które zmniejszają prawdopodobieństwo wystąpienia tego zagrożenia, dzielą się zwykle na:

  • Co jest chronione? Zastanów się nad strategią dotyczącą produktu API i wdrażaj logiczną segmentację funkcji, korzystając ze sprawdzonych metod REST, aby projektować ścieżki i zasoby udostępniane przez funkcje serwerów proxy, produktów i aplikacji interfejsu Apigee API.
  • Kto ma dostęp do Twoich zasobów interfejsu API? Określ ogólne profile użytkowników i wdroż domyślne uprawnienia dostępu o najmniejszym zakresie, korzystając z niektórych funkcji uwierzytelniania i autoryzacji Apigee, jak opisano w API1 i API2.
  • Jak egzekwowane są zasady dostępu? Używaj przepływów warunkowych i błędów, aby weryfikować ścieżkę adresu URL i czasownik wszystkich żądań do interfejsu API.

Ilustracja: ten diagram pokazuje, jak w Apigee wymuszana jest autoryzacja na poziomie funkcji przy użyciu zakresów podanych w tokenie dostępu jako uprawnień.

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

Apigee udostępnia bardzo elastyczny zestaw narzędzi, który umożliwia logiczną segmentację zasobów interfejsu API, dzięki czemu proxy interfejsów API można łączyć w dowolną liczbę usług API, z których korzystają programiści aplikacji, którzy mogą rejestrować aplikacje korzystające z Twoich usług API. Zasady dostępu można zdefiniować na dowolnym z tych poziomów.

Aby wdrożyć skuteczną autoryzację funkcjonalną i segmentację, konieczne jest określenie strategii dotyczącej interfejsu API. Częścią tego niezbędnego i ciągłego procesu jest określenie „kto” i „co” w przypadku Twoich produktów API. W tym celu musisz spojrzeć na zasoby API z perspektywy klienta i dewelopera, a następnie określić na poziomie zasobu ścieżki i czasownika HTTP, jakie typy żądań będą dozwolone.

Ilustracja: zasoby interfejsu API zgrupowane w usłudze API mogą pochodzić z jednego lub kilku interfejsów API, dzięki czemu możesz łączyć zasoby, aby tworzyć poziomy wykorzystania i granice autoryzacji.

Kontrola dostępu na poziomie funkcji za pomocą zakresów OAuth i deklaracji JWT

Chociaż opisane powyżej podejścia do autoryzacji w przypadku API1:2019 Broken object authorization dotyczą precyzyjnej kontroli dostępu na poziomie obiektu, równie ważne jest zajęcie się ogólną kontrolą dostępu na poziomie funkcji. Czy użytkownik wysyłający żądanie ma w ogóle uprawnienia do wysyłania żądań dotyczących tej ścieżki adresu URL? Ten typ zasad jest często definiowany dla poszczególnych typów użytkowników (klient, pracownik, administrator, deweloper wewnętrzny lub zewnętrzny).

Aby zmniejszyć ryzyko nieprawidłowej konfiguracji, zalecamy współpracę z zespołem ds. bezpieczeństwa. Dzięki temu będziesz mieć pewność, że potwierdzenia dotyczące użytkownika wysyłającego żądanie są zawarte w tokenie dostępu, przy użyciu zakresów OAuth lub deklaracji JWT.

Żądanie weryfikacji za pomocą przepływów warunkowych

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

  • Punkt końcowy
  • Zasób
  • czasownik czynności,
  • dowolną liczbę dodatkowych atrybutów żądania, np. parametrów zapytania.

Rodzaj ataku opisany w tym zagrożeniu jest zwykle spowodowany niewystarczającym filtrowaniem żądania do interfejsu API, co umożliwia osobie przeprowadzającej atak wykonywanie nieautoryzowanych działań lub uzyskiwanie dostępu do chronionego zasobu. Oprócz logiki warunkowej, która umożliwia filtrowanie żądań na podstawie tokenów dostępu lub roszczeń, Apigee pozwala na implementację logiki filtrowania na podstawie samego żądania.

Gdy zrozumiesz i określisz logikę biznesową produktu API oraz funkcje dozwolone przez interfejsy API, następnym krokiem będzie ograniczenie wszelkich żądań, które wykraczają poza te funkcje, za pomocą tych funkcji produktu Apigee:

  • logika warunkowa i zasady Raise Fault, które umożliwiają ograniczenie ścieżek zasobów lub czasowników na dowolnym etapie konfiguracji przepływu proxy;
  • Zasady ochrony przed zagrożeniami w przypadku JSON i XML, które chronią przed atakami opartymi na treściach przy użyciu nieprawidłowo sformatowanych ładunków żądań JSON lub XML.

API6:2019 Mass assignment

Opis zagrożenia

Niefiltrowane dane udostępniane aplikacjom klienckim za pomocą interfejsów API umożliwiają atakującym zgadywanie właściwości obiektów na podstawie żądań lub wykorzystywanie konwencji nazewnictwa punktów końcowych do uzyskiwania wskazówek, gdzie można dokonać nieautoryzowanej modyfikacji lub uzyskać dostęp do właściwości obiektów danych przechowywanych na backendzie.

To zagrożenie występuje, gdy do klienta są wysyłane niefiltrowane dane (zwykle w formacie JSON lub XML), co umożliwia atakującemu odgadnięcie szczegółów implementacji systemów backendu, a także nazw właściwości elementów danych poufnych. W wyniku tego typu ataku osoba przeprowadzająca atak może uzyskać możliwość odczytywania lub manipulowania nieodpowiednimi danymi, a w najgorszym przypadku może wykorzystać luki w zabezpieczeniach umożliwiające zdalne wykonanie kodu.

Zazwyczaj istnieją 2 aspekty, które umożliwiają tego typu zagrożenia:

  • Perspektywa projektowania interfejsu API Nigdy nie polegaj na logice aplikacji w przypadku filtrowania danych po stronie klienta, ponieważ aplikacje mogą być wykorzystywane przez osoby atakujące i uznawane za zaufane. Zawsze projektuj schemat danych interfejsu API tak, aby udostępniać tylko minimalne, niezbędne dane umożliwiające działanie usługi interfejsu API.
  • Perspektywa implementacji interfejsu API. Wdróż filtrowanie danych i weryfikację schematu, aby zapobiec nieumyślnemu udostępnianiu danych poufnych aplikacji klienckiej.

Z perspektywy usługi Apigee udostępniamy kilka przydatnych funkcji, które zapewniają solidną implementację filtrowania danych w interfejsach API.

Zasady filtrowania specyfikacji OpenAPI

Zasada OASValidation (weryfikacja specyfikacji OpenAPI) umożliwia weryfikację przychodzącego żądania lub odpowiedzi w odniesieniu do specyfikacji OpenAPI 3.0 (JSON lub YAML). Zasady te pozwalają:

  1. Zaprojektuj interfejs API, tworząc specyfikację OpenAPI (OAS).
  2. Zaimplementuj niezbędną logikę mediacji, zabezpieczeń i pamięci podręcznej, aby bezpiecznie udostępniać usługę API z backendu za pomocą Apigee.
  3. Sprawdzaj przychodzące żądania pod kątem schematu danych zdefiniowanego w specyfikacji OAS, w tym ścieżki podstawowej, czasownika, zasad dotyczących wiadomości z żądaniem i parametrów.

Zasady SOAP Message Validation

Zasada weryfikacji wiadomości SOAP umożliwia weryfikowanie żądań opartych na XML przez sprawdzanie wiadomości XML pod kątem schematu XSD lub sprawdzanie wiadomości SOAP pod kątem definicji WSDL. Możesz też użyć zasady weryfikacji wiadomości, aby potwierdzić, że ładunek wiadomości JSON lub XML jest prawidłowo sformułowany. Obejmuje to sprawdzenie w wiadomości XML lub JSON:

  • ma jeden element główny;
  • Treść nie zawiera niedozwolonych znaków
  • Obiekty i tagi są prawidłowo zagnieżdżone.
  • Tagi otwierający i zamykający są zgodne.

API7:2019 Nieprawidłowa konfiguracja zabezpieczeń

Opis zagrożenia

Błędna konfiguracja zabezpieczeń jest zwykle wynikiem niebezpiecznych konfiguracji domyślnych, niekompletnych lub doraźnych konfiguracji, otwartej pamięci w chmurze, nieprawidłowo skonfigurowanych nagłówków HTTP, niepotrzebnych metod HTTP, zbyt liberalnego współdzielenia zasobów między różnymi domenami (CORS) i szczegółowych komunikatów o błędach zawierających informacje poufne. Osoby przeprowadzające ataki często próbują znaleźć niezałatane luki, typowe punkty końcowe lub niechronione pliki i katalogi, aby uzyskać nieautoryzowany dostęp do systemu, który chcą zaatakować, lub zdobyć o nim wiedzę. Nieprawidłowe konfiguracje zabezpieczeń mogą nie tylko ujawniać wrażliwe dane użytkowników, ale także szczegóły systemu, które mogą prowadzić do pełnego naruszenia bezpieczeństwa serwera. Oto inne przypadki użycia luk w zabezpieczeniach w przypadku błędów konfiguracji zabezpieczeń:

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

Organizacje mogą podjąć różne działania, aby rozwiązać problemy związane z błędami konfiguracji zabezpieczeń i zmniejszyć ich wpływ. Obejmują one:

  1. Określanie i standaryzowanie procesów wzmacniania zabezpieczeń i stosowania poprawek
  2. Opracowywanie zasad dotyczących ekosystemu interfejsów API
  3. ograniczanie dostępu administracyjnego oraz włączanie audytu i alertów;

Przepływy współdzielone i punkty zaczepienia przepływu

Apigee obsługuje koncepcję przepływu współdzielonego, która umożliwia deweloperom interfejsów API łączenie zasad i zasobów w grupę wielokrotnego użytku. Dzięki umieszczeniu funkcji wielokrotnego użytku w jednym miejscu współdzielony przepływ pomaga zachować spójność, skrócić czas programowania i ułatwić zarządzanie kodem. Możesz umieścić współdzielony przepływ w poszczególnych serwerach proxy interfejsu API lub pójść o krok dalej i umieścić współdzielone przepływy w punktach zaczepienia przepływu, aby automatycznie wykonywać logikę współdzielonego przepływu dla każdego serwera proxy interfejsu API wdrożonego w tym samym środowisku co współdzielony przepływ.

Monitorowanie interfejsów API

Apigee udostępnia kompleksową platformę monitorowania interfejsów API. Monitorowanie interfejsów API umożliwia organizacjom proaktywne wykrywanie problemów z ruchem i wydajnością interfejsów API. Monitorowanie interfejsów API Apigee działa w połączeniu z Apigee Edge w chmurze publicznej, aby dostarczać w czasie rzeczywistym kontekstowe statystyki dotyczące wydajności interfejsów API, pomagać w szybkim diagnozowaniu problemów i ułatwiać działania naprawcze zapewniające ciągłość działania firmy.

Ilustracja: Apigee API Monitoring udostępnia szeroką gamę narzędzi do monitorowania problemów, ich analizowania i podejmowania działań w ich sprawie. Wykorzystuje najlepsze w swojej klasie funkcje analityczne Google Cloud Platform.

Apigee Sense

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

Na podstawie tej analizy organizacje mogą identyfikować klientów wysyłających niechciane żądania, a następnie podejmować działania, aby zezwalać na te żądania, blokować je lub oznaczać. Apigee Sense umożliwia ochronę interfejsów API przed wzorcami żądań, które obejmują:

  • Automatyczne zachowania, które są podobne do zachowań ludzi
  • Ciągłe próby z tego samego adresu IP
  • Nietypowe odsetki błędów
  • Podejrzane żądania klienta
  • Indeksowanie danych
  • Zbieranie kluczy
  • Nagłe wzrosty aktywności
  • Wzorce geograficzne

API8:2019 Wstrzyknięcie

Opis zagrożenia

Wstrzykiwanie do żądań interfejsu API niezaufanych 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. Atakujący będą wprowadzać do interfejsu API złośliwe dane za pomocą dostępnych wektorów wstrzykiwania, takich jak bezpośrednie dane wejściowe, parametry, zintegrowane usługi itp., oczekując, że zostaną one wysłane do interpretera. Atakujący mogą łatwo wykryć te wady podczas sprawdzania kodu źródłowego za pomocą skanerów luk w zabezpieczeniach i narzędzi do testowania nieprawidłowych danych. Udane wstrzyknięcie może prowadzić do ujawnienia informacji, co ma wpływ na poufność i utratę danych, a w niektórych przypadkach może też prowadzić do ataków DoS.

Sprawdzone metody ograniczania błędów i ataków związanych z wstrzykiwaniem obejmują ścisłe określanie danych wejściowych, takich jak schematy, typy i wzorce ciągów znaków, przeprowadzanie weryfikacji danych wejściowych, sprawdzanie limitów i wymuszanie ich w czasie działania. Platforma Apigee umożliwia weryfikację danych przychodzących za pomocą filtrów, aby zezwalać tylko na prawidłowe wartości 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 dopuszczalnym zakresie, co jest znane jako sprawdzanie 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 ryzykownych sekwencji znaków i zastąpienia ich bezpiecznymi wartościami.

Zasada ochrony 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 ocenia te treści na podstawie predefiniowanych wyrażeń regularnych. Jeśli którekolwiek z podanych wyrażeń regularnych przyjmie wartość true, wiadomość zostanie uznana za zagrożenie i odrzucona. Wyrażenie regularne, w skrócie regex, to zbiór ciągów znaków, które określają wzorzec w ciągu znaków. Wyrażenia regularne umożliwiają programowe sprawdzanie treści pod kątem wzorców. Wyrażenia regularne można stosować na przykład do sprawdzania adresu e-mail, aby upewnić się, że ma on prawidłową strukturę.

Najczęstszym zastosowaniem zasady RegularExpressionProtection jest ocena ładunków JSON i XML pod kątem złośliwych treści.

Żadne wyrażenie regularne nie może wyeliminować wszystkich ataków opartych na treści, dlatego należy połączyć ze sobą różne mechanizmy, aby zapewnić kompleksową ochronę. W tej sekcji opisujemy kilka zalecanych wzorców zapobiegania dostępowi do treści.

Platforma Apigee udostępnia kilka innych metod weryfikacji danych wejściowych:

Sprawdzanie poprawności typów treści

Typ treści odnosi się do zawartości pliku przesyłanego przez HTTP i klasyfikowanego zgodnie z dwuczęściową strukturą. Apigee zaleca weryfikowanie typów treści w przypadku żądania i odpowiedzi za pomocą logiki warunkowej, jak opisano poniżej.

API9:2019 Nieprawidłowe zarządzanie zasobami

Opis zagrożenia

Niewystarczające zarządzanie środowiskiem i jego segregacja umożliwiają atakującym dostęp do słabo zabezpieczonych punktów końcowych interfejsu API. Brak zabezpieczeń związanych z zarządzaniem powoduje też niepotrzebne udostępnianie wycofanych zasobów.

To zagrożenie można wyeliminować, korzystając z zaawansowanych funkcji Apigee do zarządzania całym cyklem życia interfejsu API. Umożliwiają one tworzenie kompleksowego modelu zarządzania, który ułatwia współpracę między zespołami, a jednocześnie pozwala rozdzielić obowiązki między osoby odpowiedzialne za bezpieczeństwo a programistów interfejsów API. Granice i ustawienia można konfigurować i utrzymywać za pomocą:

Organizacje, środowiska i wersje: wirtualne i fizyczne zabezpieczenia, które gwarantują izolację i bezpieczny proces promowania w kontekstach środowiska wykonawczego.

Kontrola dostępu oparta na rolach: tylko osoby z zespołów API, które tego potrzebują, będą mieć uprawnienia do zarządzania zmianami konfiguracji i procesem wdrażania.

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

Punkty zaczepienia przepływu: możesz egzekwować globalne zasady i wzorce, którymi można zarządzać jako uprzywilejowanymi zabezpieczeniami, których deweloperzy interfejsów API nie mogą modyfikować.

Organizacje i środowiska

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

Organizacje: organizacja to najemca najwyższego poziomu w Apigee. Umożliwia to pełne rozdzielenie ruchu, konfiguracji i użytkowników. Zgodnie ze sprawdzonymi metodami zarządzania warto mieć oddzielne organizacje produkcyjne i nieprodukcyjne. Dzięki temu unikniesz mieszania danych produkcyjnych, użytkowników i ruchu z mniej zaawansowanymi środowiskami.

Środowiska: interfejsy API w Apigee można promować w wielu stanach wdrożenia. Każdy stan jest połączony z kontekstem wykonania. Kontekst środowiska nie jest przenoszony podczas procesu promowania, dzięki czemu poufne konfiguracje nie są udostępniane użytkownikom bez uprawnień.

Wersje: wersje umożliwiają bezproblemowe 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, konieczne jest jasne określenie i rozdzielenie obowiązków między osoby odpowiedzialne za bezpieczeństwo a programistów interfejsów API. Jak wspomnieliśmy wcześniej w tym dokumencie, Apigee ma elastyczne możliwości kontroli dostępu opartej na rolach, które umożliwiają przypisywanie uprawnień do ról niestandardowych. W przypadku tego konkretnego zagrożenia role mogą mieć ograniczony zakres uprawnień w poszczególnych organizacjach, środowiskach lub bardziej szczegółowych konfiguracjach. Zalecamy ograniczenie uprawnień do zmiany stanu wdrożenia interfejsów API w środowiskach, a także zadbanie o to, aby programiści nie mieli dostępu do globalnych bibliotek zabezpieczeń (Flow Hooks) ani nie mogli ich modyfikować. Te ograniczone role zapobiegną niechcianym zmianom w globalnych zasadach zabezpieczeń, które mają szeroki zakres zarówno w przypadku starszych, jak i obecnych opublikowanych punktów końcowych.

Dokumentacja interfejsu Audience Management API

Portal dla programistów to kluczowy element strategii dotyczącej interfejsu API. Umożliwia on prowadzenie obszernego spisu całej dokumentacji związanej z interfejsami API, w tym hostów/punktów końcowych, zasobów, operacji, schematów ładunku i innych. W Apigee możesz grupować interfejsy API za pomocą konstrukcji usługi API. Produkty API są definiowane przez pakiety zasobów i operacji, które należą do tego samego kontekstu biznesowego i bezpieczeństwa (np. plan usługi, domena biznesowa, kategoria, hierarchia firmy itp.).

Dzięki zintegrowanemu portalowi dla deweloperów Apigee możesz publikować usługi API i ograniczać widoczność opublikowanych treści, zarządzając odbiorcami docelowymi. Ta funkcja jest zgodna ze strategią segmentacji treści, która jest dostosowana do wymagań biznesowych i związanych z bezpieczeństwem.

Flow Hooks

Procesy promowania i udostępniania interfejsów API muszą zawsze obejmować procesy zgodności z wymaganiami dotyczącymi bezpieczeństwa i certyfikacji. Aby zespoły API mogły skutecznie tworzyć zabezpieczenia, które gwarantują rozdzielenie obowiązków przy zachowaniu zwinnych cykli wydawniczych, muszą korzystać z odpowiednich narzędzi.

Apigee umożliwia zwiększenie obowiązków związanych z zarządzaniem zabezpieczeniami przez egzekwowanie zasad globalnych za pomocą punktów zaczepienia przepływu. Tymi zasadami globalnymi można zarządzać jako uprzywilejowanymi zabezpieczeniami, których deweloperzy interfejsów API nie mogą modyfikować. Gwarantuje to podział obowiązków i zwiększa elastyczność dzięki stosowaniu domyślnych zabezpieczeń, a tym samym zapewnia zgodność z wymaganiami dotyczącymi bezpieczeństwa w przypadku wszystkich interfejsów API wdrożonych w danym środowisku wykonawczym.

Ilustracja: uprawnione zabezpieczenia można skonfigurować w Apigee za pomocą punktów zaczepienia przepływu i przepływów współdzielonych. Osoby odpowiedzialne za bezpieczeństwo odpowiadają za utrzymywanie globalnych zasad związanych z bezpieczeństwem. Te funkcje gwarantują rozdzielenie obowiązków i wspierają zwinne cykle życia rozwoju.

API10:2019 – niewystarczające logowanie i monitorowanie

Opis zagrożenia

Niewystarczające rejestrowanie, monitorowanie i alerty umożliwiają wykrywanie trwających ataków, dlatego należy opracować strategię uzyskiwania informacji o krytycznych zdarzeniach, które mają wpływ 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 itp.
  • Zasady zarządzania zdarzeniami: gwarantują, że każde zdarzenie powinno być możliwe do śledzenia aż do jego źródła. Zdarzenia powinny też być podzielone na kategorie według ważności i wpływu na firmę.
  • Raporty i audyty: 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 cykle wzmacniania mogą być przeprowadzane przez zainteresowane strony w celu dostosowania wzorców wykrywania na podstawie danych historycznych.

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

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

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

Zasady wywołań usługi: 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 analizuj je za pomocą gotowych lub dostosowanych raportów. Tworzenie alertów na podstawie trendów i zarządzanie nimi oraz analizowanie anomalii w ruchu.

Monitorowanie interfejsów API: jak opisano wcześniej, to narzędzie zapewnia funkcje alertów, które mogą być wywoływane na podstawie krytycznych zdarzeń. Dzienniki ruchu można dalej analizować i na ich podstawie podejmować działania.