Udostępnij za pośrednictwem

Zalecenia dotyczące ograniczania zagrożeń OWASP API Security Top 10 przy użyciu usługi API Management

  • Artykuł

DOTYCZY: Wszystkie warstwy usługi API Management

Uwaga

Ten artykuł został zaktualizowany, aby odzwierciedlić najnowszą listę OWASP API Security Top 10 dla 2023 roku.

Program Open Web Application Security Project (OWASP) Foundation pracuje nad zwiększeniem bezpieczeństwa oprogramowania za pośrednictwem prowadzonych przez społeczność projektów oprogramowania open source, setek rozdziałów na całym świecie, dziesiątek tysięcy członków oraz hostując lokalne i globalne konferencje.

Projekt zabezpieczeń interfejsu API OWASP koncentruje się na strategiach i rozwiązaniach, aby zrozumieć i ograniczyć unikatowe luki w zabezpieczeniach i zagrożenia bezpieczeństwa interfejsów API. W tym artykule omówiono najnowsze zalecenia, aby ograniczyć 10 najważniejszych zagrożeń interfejsu API zidentyfikowanych przez firmę OWASP na liście z 2023 r. przy użyciu usługi Azure API Management.

Mimo że usługa API Management zapewnia kompleksowe mechanizmy kontroli zabezpieczeń interfejsu API, inne usługi firmy Microsoft zapewniają dodatkowe funkcje do wykrywania lub ochrony przed zagrożeniami interfejsu API OWASP:

Przerwana autoryzacja na poziomie obiektu

Obiekty interfejsu API, które nie są chronione przy użyciu odpowiedniego poziomu autoryzacji, mogą być narażone na wycieki danych i nieautoryzowane manipulowanie danymi za pośrednictwem słabych identyfikatorów dostępu do obiektów. Na przykład osoba atakująca może wykorzystać identyfikator obiektu całkowitego, który można iterować.

Więcej informacji o tym zagrożeniu: Autoryzacja na poziomie uszkodzonego obiektu api1:2023

Zalecenia

  • Najlepszym miejscem do zaimplementowania autoryzacji na poziomie obiektu jest sam interfejs API zaplecza. Na zapleczu można podejmować prawidłowe decyzje dotyczące autoryzacji na poziomie żądania (lub obiektu), jeśli ma to zastosowanie, przy użyciu logiki stosowanej do domeny i interfejsu API. Rozważ scenariusze, w których dane żądanie może zwracać różne poziomy szczegółowości w odpowiedzi, w zależności od uprawnień i autoryzacji osoby żądającej.

  • Jeśli w zapleczu nie można zmienić bieżącego narażonego interfejsu API, usługa API Management może być używana jako rezerwa. Na przykład:

    • Użyj zasad niestandardowych, aby zaimplementować autoryzację na poziomie obiektu, jeśli nie została zaimplementowana w zapleczu.

    • Zaimplementuj niestandardowe zasady, aby mapować identyfikatory z żądania do zaplecza i z zaplecza na klienta, aby identyfikatory wewnętrzne nie zostały ujawnione.

      W takich przypadkach zasady niestandardowe mogą być wyrażeniem zasad z wyszukiwaniem (na przykład słownikiem) lub integracją z inną usługą za pomocą zasad wysyłania żądań.

  • W przypadku scenariuszy graphQL wymuś autoryzację na poziomie obiektu za pomocą zasad validate-graphql-request przy użyciu authorize elementu .

Przerwane uwierzytelnianie

Mechanizm uwierzytelniania witryny lub interfejsu API jest szczególnie narażony, ponieważ jest otwarty dla użytkowników anonimowych. Zasoby i punkty końcowe wymagane do uwierzytelniania, w tym zapomniane hasła lub resetowanie przepływów haseł, powinny być chronione, aby zapobiec wykorzystywaniu.

Więcej informacji o tym zagrożeniu: Uwierzytelnianie przerwane za pomocą interfejsu API2:2023

Zalecenia

  • Użyj firmy Microsoft Entra do zaimplementowania uwierzytelniania interfejsu API. Firma Microsoft Entra automatycznie zapewnia chronione, odporne i geograficznie rozproszone punkty końcowe logowania. Użyj zasad validate-azure-ad-token, aby zweryfikować tokeny entra firmy Microsoft w przychodzących żądaniach interfejsu API.
  • Jeśli wymagane jest uwierzytelnianie, usługa API Management obsługuje walidację tokenów OAuth 2, uwierzytelniania podstawowego, certyfikatów klienta i kluczy interfejsu API.
    • Upewnij się, że prawidłowa konfiguracja metod uwierzytelniania. Na przykład ustaw require-expiration-time parametr i require-signed-tokens na true wartość podczas sprawdzania poprawności tokenów OAuth2 przy użyciu zasad validate-jwt .
  • Ograniczanie szybkości można wykorzystać w celu zmniejszenia skuteczności ataków siłowych.
  • Filtrowanie adresów IP klienta może służyć do zmniejszenia obszaru obszaru podatnego na ataki. Sieciowe grupy zabezpieczeń można stosować do sieci wirtualnych zintegrowanych z usługą API Management.
  • Jeśli to możliwe, uwierzytelnij się w zapleczach z usługi API Management za pomocą bezpiecznych protokołów oraz tożsamości zarządzanej lub menedżera poświadczeń w celu uwierzytelniania w zapleczach.
  • Upewnij się, że tokeny lub klucze są przekazywane w nagłówkach, a nie adresy URL dla żądań przychodzących do usługi API Management i żądań wychodzących do zaplecza.
  • Użyj firmy Microsoft Entra, aby zabezpieczyć dostęp do portalu deweloperów usługi API Management.

Autoryzacja na poziomie uszkodzonej właściwości obiektu

Dobry projekt interfejsu API jest zwodniczo trudny. Często, szczególnie w przypadku starszych interfejsów API, które ewoluowały wraz z upływem czasu, interfejsy żądań i odpowiedzi zawierają więcej pól danych niż wymagają aplikacje zużywające, umożliwiając ataki polegających na wstrzyknięciu danych. Osoby atakujące mogą również odnajdywać nieudokumentowane interfejsy. Te luki w zabezpieczeniach mogą spowodować uzyskanie poufnych danych osobom atakującym.

Więcej informacji o tym zagrożeniu: autoryzacja na poziomie właściwości uszkodzonego obiektu API3:2023

Zalecenia

  • Najlepszym podejściem do ograniczania tej luki w zabezpieczeniach jest zapewnienie, że interfejsy zewnętrzne zdefiniowane w interfejsie API zaplecza są starannie zaprojektowane i, najlepiej, niezależnie od trwałości danych. Powinny zawierać tylko pola wymagane przez użytkowników interfejsu API. Interfejsy API powinny być często przeglądane, a starsze pola przestarzałe, a następnie usuwane.
  • W usłudze API Management użyj poprawek , aby bezpiecznie kontrolować zmiany powodujące niezgodność, na przykład dodanie pola do interfejsu i wersji w celu zaimplementowania zmian powodujących niezgodność. Należy również wersję interfejsów zaplecza, które zwykle mają inny cykl życia niż interfejsy API dostępne dla konsumentów.
  • Rozdziel zewnętrzne interfejsy API z wewnętrznej implementacji danych. Unikaj wiązania kontraktów interfejsu API bezpośrednio z kontraktami danych w usługach zaplecza.
  • Jeśli nie można zmienić projektu interfejsu zaplecza i nadmierne dane są istotne, użyj zasad przekształcania usługi API Management, aby przepisać ładunki odpowiedzi i maskować lub filtrować dane. Walidacja zawartości w usłudze API Management może służyć ze schematem XML lub JSON w celu blokowania odpowiedzi z nieudokumentowanych właściwościami lub nieprawidłowymi wartościami. Na przykład usuń niepotrzebne właściwości JSON z treści odpowiedzi. Blokowanie żądań z nieudokumentowanymi właściwościami ogranicza ataki, jednocześnie blokując odpowiedzi z nieudokumentowanych właściwościami utrudnia odwrócenie potencjalnych wektorów ataków. Zasady weryfikacji zawartości obsługują również blokowanie odpowiedzi przekraczających określony rozmiar.
  • Użyj zasad validate-status-code, aby zablokować odpowiedzi z błędami niezdefiniowanym w schemacie interfejsu API.
  • Użyj zasad validate-headers, aby zablokować odpowiedzi z nagłówkami, które nie są zdefiniowane w schemacie lub nie są zgodne z ich definicją w schemacie. Usuń niechciane nagłówki z zasadami set-header .
  • W przypadku scenariuszy graphQL użyj zasad validate-graphql-request , aby zweryfikować żądania GraphQL, autoryzować dostęp do określonych ścieżek zapytań i ograniczyć rozmiar odpowiedzi.

Nieograniczone użycie zasobów

Interfejsy API wymagają uruchomienia zasobów, takich jak pamięć lub procesor CPU, i mogą obejmować integrację podrzędną reprezentującą koszt operacyjny (na przykład usługi płatności za żądanie). Stosowanie limitów może pomóc chronić interfejsy API przed nadmiernym użyciem zasobów.

Więcej informacji o tym zagrożeniu: Użycie nieograniczonego zasobu interfejsu API4:2023

Zalecenia

  • Użyj zasad rate-limit-by-key lub rate-limit , aby zastosować ograniczanie przepustowości w krótszych oknach czasowych. Stosowanie bardziej rygorystycznych zasad ograniczania szybkości dla poufnych punktów końcowych, takich jak resetowanie haseł, logowanie lub operacje rejestracji, lub punkty końcowe, które zużywają znaczne zasoby.
  • Użyj zasad limitu przydziału według klucza lub limitu przydziału, aby kontrolować dozwoloną liczbę wywołań interfejsu API lub przepustowości przez dłuższe przedziały czasu.
  • Zoptymalizuj wydajność dzięki wbudowanej pamięci podręcznej, co zmniejsza zużycie procesora CPU, pamięci i zasobów sieciowych na potrzeby niektórych operacji.
  • Zastosuj zasady walidacji.
  • W przypadku interfejsów API generacyjnych sztucznej inteligencji:
    • Użyj buforowania semantycznego, aby zmniejszyć obciążenie zaplecza.
    • Użyj ograniczania tokenów, aby kontrolować zużycie i koszty.
    • Emituj metryki użycia tokenu w celu monitorowania wykorzystania tokenu i konfigurowania alertów.
  • Zminimalizuj czas odpowiedzi usługi zaplecza. Im dłużej usługa zaplecza odpowiada, tym dłużej połączenie jest zajmowane w usłudze API Management, co zmniejsza liczbę żądań, które mogą być obsługiwane w danym przedziale czasu.
  • Zastosuj zasady MECHANIZMU CORS, aby kontrolować witryny internetowe, które mogą ładować zasoby obsługiwane za pośrednictwem interfejsu API. Aby uniknąć nadmiernie permisywnych konfiguracji, nie używaj wartości wieloznacznych (*) w zasadach MECHANIZMU CORS.
  • Platforma Azure ma zarówno ochronę na poziomie platformy, jak i rozszerzoną ochronę przed atakami typu "rozproszona odmowa usługi", jednak ochronę aplikacji (warstwa 7) dla interfejsów API można poprawić, wdrażając usługę ochrony botów przed usługą API Management — na przykład aplikacja systemu Azure Gateway, Azure Front Door lub Azure DDoS Protection. W przypadku korzystania z zasad zapory aplikacji internetowej z usługą aplikacja systemu Azure Gateway lub Azure Front Door rozważ użycie Microsoft_BotManagerRuleSet_1.0.

Przerwana autoryzacja na poziomie funkcji

Złożone zasady kontroli dostępu z różnymi hierarchiami, grupami i rolami oraz niejasne rozdzielenie funkcji administracyjnych i regularnych prowadzą do błędów autoryzacji. Wykorzystując te problemy, osoby atakujące uzyskują dostęp do zasobów innych użytkowników lub funkcji administracyjnych.

Więcej informacji o tym zagrożeniu: autoryzacja na poziomie przerwanej funkcji api5:2023

Zalecenia

  • Domyślnie chroń wszystkie punkty końcowe interfejsu API w usłudze API Management przy użyciu kluczy subskrypcji lub zasad autoryzacji na poziomie wszystkich interfejsów API. Jeśli ma to zastosowanie, zdefiniuj inne zasady autoryzacji dla określonych interfejsów API lub operacji interfejsu API.
  • Zweryfikuj tokeny OAuth przy użyciu zasad.
    • Użyj zasad validate-azure-ad-token , aby zweryfikować tokeny firmy Microsoft. Określ wszystkie wymagane oświadczenia i, jeśli ma to zastosowanie, określ autoryzowane aplikacje.
    • W przypadku sprawdzania poprawności tokenów nie wystawionych przez firmę Microsoft Entra zdefiniuj zasady validate-jwt i wymuś wymagane oświadczenia tokenu. Jeśli to możliwe, wymagaj czasu wygaśnięcia.
    • Jeśli to możliwe, użyj zaszyfrowanych tokenów lub wyświetl listę określonych aplikacji w celu uzyskania dostępu.
    • Monitoruj i przeglądaj żądania odrzucone z powodu braku autoryzacji.
  • Użyj sieci wirtualnej platformy Azure lub usługi Private Link, aby ukryć punkty końcowe interfejsu API z Internetu. Dowiedz się więcej o opcjach sieci wirtualnej za pomocą usługi API Management.
  • Nie należy definiować operacji interfejsu API z symbolami wieloznacznymi (czyli interfejsów API "catch-all" ze * ścieżką). Upewnij się, że usługa API Management obsługuje tylko żądania jawnie zdefiniowanych punktów końcowych, a żądania do niezdefiniowanych punktów końcowych są odrzucane.
  • Nie publikuj interfejsów API z otwartymi produktami, które nie wymagają subskrypcji.
  • Jeśli są znane adresy IP klientów, użyj zasad filtru ip, aby zezwolić na ruch tylko z autoryzowanych adresów IP.
  • Użyj zasad validate-client-certificate, aby wymusić, że certyfikat przedstawiony przez klienta w wystąpieniu usługi API Management jest zgodny z określonymi regułami walidacji i oświadczeniami.

Nieograniczony dostęp do poufnych przepływów biznesowych

Interfejsy API mogą uwidaczniać szeroką gamę funkcji aplikacji zużywających dane. Ważne jest, aby autorzy interfejsów API rozumieli przepływy biznesowe, które udostępnia interfejs API i powiązaną wrażliwość. Istnieje większe ryzyko dla firmy, jeśli interfejsy API ujawniające poufne przepływy nie implementują odpowiednich zabezpieczeń.

Więcej informacji o tym zagrożeniu: Interfejs API6:2023 Nieograniczony dostęp do poufnych przepływów biznesowych

Zalecenia

  • Zmniejsz lub zablokuj dostęp na podstawie odcisków palców klientów. Na przykład użyj zasad return-response z wybranymi zasadami, aby zablokować ruch z przeglądarek bezgłowych w oparciu o nagłówek User-Agent lub spójność innych nagłówków.
  • Użyj zasad validate-parameters , aby wymusić, że nagłówki żądań są zgodne ze specyfikacją interfejsu API.
  • Użyj zasad filtru ip, aby zezwolić na żądania tylko ze znanych adresów IP lub odmówić dostępu z określonych adresów IP.
  • Używanie funkcji sieci prywatnej w celu ograniczenia łączności zewnętrznej z wewnętrznymi interfejsami API.
  • Użyj zasad rate-limit-by-key , aby ograniczyć wzrost użycia interfejsu API na podstawie tożsamości użytkownika, adresu IP lub innej wartości.
  • Usługa Front API Management z usługą aplikacja systemu Azure Gateway lub Azure DDoS Protection w celu wykrywania i blokowania ruchu bota.

Fałszerzność żądania po stronie serwera

Luka w zabezpieczeniach fałszerstwa żądania po stronie serwera może wystąpić, gdy interfejs API pobiera zasób podrzędny na podstawie wartości adresu URL, który został przekazany przez obiekt wywołujący interfejs API bez odpowiednich testów poprawności.

Więcej informacji o tym zagrożeniu: Fałszerz żądania po stronie serwera API7:2023

Zalecenia

  • Jeśli to możliwe, nie używaj adresów URL podanych w ładunkach klienta, na przykład jako parametrów dla adresów URL zaplecza, zasad wysyłania żądań ani zasad ponownego zapisywania adresów URL .
  • Jeśli usługa API Management lub usługi zaplecza używają adresów URL podanych w ładunku żądania dla logiki biznesowej, zdefiniuj i wymuś ograniczoną listę nazw hostów, portów, typów multimediów lub innych atrybutów z zasadami w usłudze API Management, takimi jak wybieranie zasad i wyrażeń zasad.
  • Zdefiniuj timeout atrybut w zasadach żądania przesyłania dalej i wysyłania żądań .
  • Weryfikowanie i oczyszczanie danych żądania i odpowiedzi przy użyciu zasad walidacji. W razie potrzeby użyj zasad zestawu treści , aby przetworzyć odpowiedź i uniknąć zwracania nieprzetworzonych danych.
  • Użyj sieci prywatnej, aby ograniczyć łączność. Jeśli na przykład interfejs API nie musi być publiczny, ogranicz łączność z Internetem, aby zmniejszyć obszar ataków.

Błędna konfiguracja zabezpieczeń

Osoby atakujące mogą próbować wykorzystać luki w błędzie konfiguracji zabezpieczeń, takie jak:

  • Brak wzmacniania zabezpieczeń
  • Niepotrzebnie włączone funkcje
  • Połączenia sieciowe niepotrzebnie otwarte dla Internetu
  • Używanie słabych protokołów lub szyfrowania

Więcej informacji o tym zagrożeniu: Błędna konfiguracja zabezpieczeń interfejsu API8:2023

Zalecenia

  • Poprawnie skonfiguruj protokół TLS bramy. Nie używaj protokołów podatnych na zagrożenia (na przykład TLS 1.0, 1.1) ani szyfrów.
  • Skonfiguruj interfejsy API tak, aby akceptowały tylko zaszyfrowany ruch, na przykład za pośrednictwem protokołów HTTPS lub WSS. To ustawienie można przeprowadzać inspekcję i wymuszać przy użyciu usługi Azure Policy.
  • Rozważ wdrożenie usługi API Management za prywatnym punktem końcowym lub dołączone do sieci wirtualnej wdrożonej w trybie wewnętrznym. W sieciach wewnętrznych dostęp można kontrolować z sieci prywatnej (za pośrednictwem zapory lub sieciowych grup zabezpieczeń) i z Internetu (za pośrednictwem zwrotnego serwera proxy).
  • Użyj zasad usługi Azure API Management:
    • Zawsze dziedzicz zasady nadrzędne za pomocą tagu <base> .
    • W przypadku korzystania z protokołu OAuth 2.0 skonfiguruj i przetestuj zasady validate-jwt , aby sprawdzić istnienie i ważność tokenu przed dotarciem do zaplecza. Automatycznie sprawdź czas wygaśnięcia tokenu, podpis tokenu i wystawcę. Wymuszanie oświadczeń, odbiorców, wygasania tokenu i podpisu tokenu za pomocą ustawień zasad. Jeśli używasz firmy Microsoft Entra, zasady validate-azure-ad-token zapewniają bardziej kompleksowy i łatwiejszy sposób weryfikowania tokenów zabezpieczających.
    • Skonfiguruj zasady MECHANIZMU CORS i nie używaj symboli wieloznacznych * dla żadnej opcji konfiguracji. Zamiast tego jawnie wyświetl dozwolone wartości.
    • Ustaw zasady walidacji w środowiskach produkcyjnych, aby zweryfikować schematy JSON i XML, nagłówki, parametry zapytania i kody stanu oraz wymusić maksymalny rozmiar żądania lub odpowiedzi.
    • Jeśli usługa API Management znajduje się poza granicą sieci, weryfikacja adresów IP klienta jest nadal możliwa przy użyciu zasad ograniczeń adresów IP wywołujących. Upewnij się, że używa listy dozwolonych, a nie listy zablokowanych.
    • Jeśli certyfikaty klienta są używane między obiektem wywołującym i usługą API Management, użyj zasad validate-client-certificate . Upewnij się, że validate-revocationwszystkie atrybuty , validate-trust, validate-not-beforei validate-not-after są ustawione na truewartość .
  • Certyfikaty klienta (wzajemne protokoły TLS) można również stosować między usługą API Management i zapleczem. Zaplecze powinno:
    • Konfigurowanie poświadczeń autoryzacji
    • Zweryfikuj łańcuch certyfikatów, jeśli ma to zastosowanie
    • Zweryfikuj nazwę certyfikatu, jeśli ma to zastosowanie
    • W przypadku scenariuszy graphQL użyj zasad validate-graphQL-request . Upewnij się, że authorization element i max-depth max-size atrybuty zostały ustawione.
  • Nie przechowuj wpisów tajnych w plikach zasad ani w kontroli źródła. Zawsze używaj usługi API Management nazwanych wartości lub pobieraj wpisy tajne w czasie wykonywania przy użyciu niestandardowych wyrażeń zasad. Nazwane wartości powinny być zintegrowane z usługą Azure Key Vault lub zaszyfrowane w usłudze API Management, oznaczając je jako "wpis tajny". Nigdy nie przechowuj wpisów tajnych w postaci zwykłego tekstu o nazwach wartości.
  • Publikowanie interfejsów API za pośrednictwem produktów, które wymagają subskrypcji. Nie używaj otwartych produktów , które nie wymagają subskrypcji.
  • Upewnij się, że interfejsy API wymagają kluczy subskrypcji, nawet jeśli wszystkie produkty są skonfigurowane do wymagania kluczy subskrypcji. Dowiedz się więcej
  • Wymagaj zatwierdzenia subskrypcji dla wszystkich produktów i dokładnie przejrzyj wszystkie żądania subskrypcji.
  • Integracja z usługą Key Vault umożliwia zarządzanie wszystkimi certyfikatami. Umożliwia to scentralizowanie zarządzania certyfikatami i ułatwia wykonywanie zadań zarządzania operacjami, takich jak odnawianie lub odwoływanie certyfikatów. Użyj tożsamości zarządzanej do uwierzytelniania w magazynach kluczy.
  • W przypadku korzystania z własnej bramy upewnij się, że istnieje proces okresowy aktualizowania obrazu do najnowszej wersji.
  • Reprezentują usługi zaplecza jako jednostki zaplecza. Skonfiguruj poświadczenia autoryzacji, walidację łańcucha certyfikatów i walidację nazwy certyfikatu, jeśli ma to zastosowanie.
  • Jeśli to możliwe, użyj menedżera poświadczeń lub tożsamości zarządzanej do uwierzytelniania w usługach zaplecza.
  • W przypadku korzystania z portalu dla deweloperów:
    • Jeśli zdecydujesz się samodzielnie hostować portal dla deweloperów, upewnij się, że istnieje proces okresowy aktualizowania portalu własnego do najnowszej wersji. Aktualizacje domyślnej wersji zarządzanej są automatyczne.
    • Użyj identyfikatora Microsoft Entra lub usługi Azure Active Directory B2C , aby utworzyć konto użytkownika i zalogować się. Wyłącz domyślną nazwę użytkownika i uwierzytelnianie hasłem, co jest mniej bezpieczne.
    • Przypisz grupy użytkowników do produktów, aby kontrolować widoczność interfejsów API w portalu.
  • Użyj usługi Azure Policy , aby wymusić konfigurację na poziomie zasobów usługi API Management i uprawnienia kontroli dostępu opartej na rolach (RBAC) w celu kontrolowania dostępu do zasobów. Przyznaj każdemu użytkownikowi minimalne wymagane uprawnienia.
  • Użyj procesu DevOps i podejścia infrastruktury jako kodu poza środowiskiem deweloperskim, aby zapewnić spójność zawartości i konfiguracji usługi API Management oraz zminimalizować błędy ludzkie.
  • Nie używaj żadnych przestarzałych funkcji.

Niewłaściwe zarządzanie spisem

Luki w zabezpieczeniach związane z niewłaściwym zarządzaniem zasobami obejmują:

  • Brak odpowiedniej dokumentacji interfejsu API lub informacji o własności
  • Nadmierna liczba starszych wersji interfejsu API, które mogą brakować poprawek zabezpieczeń

Więcej informacji o tym zagrożeniu: Interfejs API9:2023 Niewłaściwe zarządzanie spisem

Zalecenia

  • Użyj dobrze zdefiniowanej specyfikacji interfejsu OpenAPI jako źródła do importowania interfejsów API REST. Specyfikacja umożliwia hermetyzację definicji interfejsu API, w tym metadanych samodzielnego dokumentowania.
  • Używaj interfejsów API z precyzyjnymi ścieżkami, schematami danych, nagłówkami, parametrami zapytania i kodami stanu. Unikaj operacji z symbolami wieloznacznymi. Podaj opisy dla każdego interfejsu API i operacji oraz dołącz informacje kontaktowe i licencyjne.
  • Unikaj punktów końcowych, które nie przyczyniają się bezpośrednio do celu biznesowego. Niepotrzebnie zwiększają obszar powierzchni ataków i utrudniają rozwijanie interfejsu API.
  • Użyj poprawek i wersji w usłudze API Management, aby zarządzać zmianami interfejsu API. Mieć silną strategię przechowywania wersji zaplecza i zatwierdzić maksymalną liczbę obsługiwanych wersji interfejsu API (na przykład 2 lub 3 wcześniejsze wersje). Zaplanuj szybkie wycofanie i ostatecznie usunięcie starszych, często mniej bezpiecznych wersji interfejsu API. Upewnij się, że mechanizmy kontroli zabezpieczeń są implementowane we wszystkich dostępnych wersjach interfejsu API.
  • Oddzielne środowiska (takie jak programowanie, testowanie i produkcja) przy użyciu różnych usług API Management. Upewnij się, że każda usługa API Management łączy się z jej zależnościami w tym samym środowisku. Na przykład w środowisku testowym testowy zasób usługi API Management powinien połączyć się z testowym zasobem usługi Azure Key Vault i testowymi wersjami usług zaplecza. Użyj automatyzacji DevOps i rozwiązań infrastruktury jako kodu, aby zapewnić spójność i dokładność między środowiskami i zmniejszyć liczbę błędów ludzkich.
  • Izolowanie uprawnień administracyjnych do interfejsów API i powiązanych zasobów przy użyciu obszarów roboczych.
  • Użyj tagów, aby organizować interfejsy API i produkty i grupować je do publikowania.
  • Publikowanie interfejsów API do użycia za pośrednictwem portalu dla deweloperów. Upewnij się, że dokumentacja interfejsu API jest aktualna.
  • Odnajdywanie nieudokumentowanych lub niezarządzanych interfejsów API i uwidacznianie ich za pośrednictwem usługi API Management w celu uzyskania lepszej kontroli.
  • Centrum interfejsów API platformy Azure umożliwia utrzymanie kompleksowego, scentralizowanego spisu interfejsów API, wersji i wdrożeń, nawet jeśli interfejsy API nie są zarządzane w usłudze Azure API Management.

Niebezpieczne użycie interfejsów API

Zasoby uzyskane za pośrednictwem integracji podrzędnych są zwykle bardziej zaufane niż dane wejściowe interfejsu API od obiektu wywołującego lub użytkownika końcowego. Jeśli nie zastosowano odpowiednich standardów oczyszczania i zabezpieczeń, interfejs API może być narażony na zagrożenia, nawet jeśli integracja jest dostarczana za pośrednictwem zaufanej usługi.

Więcej informacji o tym zagrożeniu: Interfejs API10:2023 Niebezpieczne użycie interfejsów API

Zalecenia

  • Rozważ użycie usługi API Management do działania jako fasady dla zależności podrzędnych, z którymi integrują się interfejsy API zaplecza.
  • Jeśli zależności podrzędne są frontonowane za pomocą usługi API Management lub jeśli zależności podrzędne są używane z zasadami wysyłania żądań w usłudze API Management, skorzystaj z zaleceń z innych sekcji tej dokumentacji, aby zapewnić ich bezpieczne i kontrolowane użycie, w tym:
    • Upewnij się, że bezpieczny transport jest włączony i wymuszaj konfigurację protokołu TLS/SSL
    • Jeśli to możliwe, uwierzytelnij się przy użyciu menedżera poświadczeń lub tożsamości zarządzanej
    • Kontrolowanie użycia za pomocą zasad rate-limit-by-key i quota-limit-by-key
    • Rejestrowanie lub blokowanie odpowiedzi niezgodnych ze specyfikacją interfejsu API przy użyciu zasad validate-content i validate-header
    • Przekształcanie odpowiedzi za pomocą zasad zestawu treści, na przykład w celu usunięcia niepotrzebnych lub poufnych informacji
    • Konfigurowanie limitów czasu i ograniczenia współbieżności

Powiązana zawartość

Dowiedz się więcej na następujące tematy: