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

DOTYCZY: Wszystkie warstwy usługi API Management

Uwaga

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

Fundacja Open Web Application Security Project (OWASP) działa na rzecz poprawy bezpieczeństwa oprogramowania za pośrednictwem prowadzonych przez społeczność projektów oprogramowania open source, setek oddziałó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:

Naruszona 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 typu integer, który można iterować.

Więcej informacji o tym zagrożeniu: API1:2023 Naruszona autoryzacja na poziomie obiektu

Zalecenia

  • Najlepszym miejscem do zaimplementowania autoryzacji na poziomie obiektu jest samo API backendu. 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 żądającego.

  • Jeśli w zapleczu nie można zmienić bieżącego podatnego na zagrożenia interfejsu API, usługa API Management może być używana jako rozwiązanie awaryjne. Na przykład:

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

    • 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 policy z wyszukiwaniem (na przykład w słowniku) lub integracją z inną usługą za pomocą zasady send-request.

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

Nieprawidłowe 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 procesy odzyskiwania lub resetowania hasła, powinny być chronione, aby zapobiec ich wykorzystaniu.

Więcej informacji o tym zagrożeniu: API2:2023 Niewłaściwe uwierzytelnianie

Zalecenia

Naruszona autoryzacja na poziomie 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 korzystające z nich, umożliwiając ataki polegające na wstrzyknięciu danych. Osoby atakujące mogą również odnajdywać nieudokumentowane interfejsy. Te luki w zabezpieczeniach mogą umożliwić atakującemu uzyskanie poufnych danych.

Więcej informacji o tym zagrożeniu: API3:2023 Broken Object Property Level Authorization

Zalecenia

  • Najlepszym podejściem do ograniczania tej luki w zabezpieczeniach jest zapewnienie, że interfejsy zewnętrzne zdefiniowane w interfejsie API zaplecza są starannie zaprojektowane oraz, najlepiej, niezależne od persystencji danych. Powinny zawierać tylko pola wymagane przez użytkowników interfejsu API. Interfejsy API powinny być często przeglądane, a starsze pola należy oznaczyć jako przestarzałe, a następnie usuwać.
  • W usłudze API Management użyj rewizji, aby bezpiecznie kontrolować zmiany niepowodujące niezgodności, na przykład dodanie pola do interfejsu, i wersji w celu zaimplementowania zmian powodujących niezgodność. Należy również wersjonować interfejsy zaplecza, które zwykle mają inny cykl życia niż interfejsy API dostępne dla konsumentów.
  • Rozdziel zewnętrzne interfejsy API od 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 problemem jest nadmiar danych, użyj zasad transformacji w API Management, aby przepisać treść odpowiedzi i maskować lub filtrować dane. Walidacja zawartości w usłudze API Management może być używana ze schematem XML lub JSON w celu blokowania odpowiedzi zawierających nieudokumentowane właściwości lub nieprawidłowe wartości. 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 blokowanie odpowiedzi z nieudokumentowanymi właściwościami utrudnia analizę potencjalnych wektorów ataku. Zasady validate-content obsługują również blokowanie odpowiedzi przekraczających określony rozmiar.
  • Użyj zasady validate-status-code, aby zablokować odpowiedzi z błędami niezdefiniowanymi 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 za pomocą polityki 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ą zasobów do działania, takich jak pamięć lub procesor CPU, i mogą obejmować integracje zależne, które stanowią 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: API4:2023 Nieograniczone zużycie zasobów

Zalecenia

  • Użyj zasad rate-limit-by-key lub rate-limit , aby zastosować ograniczanie przepustowości w krótszych oknach czasowych. Stosuj bardziej rygorystyczne zasady ograniczania szybkości dla poufnych punktów końcowych, takich jak resetowanie haseł, logowanie lub operacje rejestracji, lub punktów końcowych, które zużywają znaczne zasoby.
  • Użyj zasad quota-by-key lub quota-limit, aby kontrolować dozwoloną liczbę wywołań interfejsu API lub przepustowość w dłuższych przedziałach 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.
    • Użyj atrybutu max-size w zasadzie validate-content, aby wymusić maksymalny rozmiar żądań i odpowiedzi
    • Zdefiniuj schematy i właściwości, takie jak długość ciągu lub maksymalny rozmiar tablicy, w specyfikacji interfejsu API. Użyj zasad validate-content, validate-parameters i validate-headers, aby wymusić te schematy dla żądań i odpowiedzi.
    • Użyj zasady validate-graphql-request dla interfejsów API graphQL i skonfiguruj parametry max-depth i max-size.
    • Konfigurowanie alertów w usłudze Azure Monitor pod kątem nadmiernego użycia danych przez użytkowników.
  • W przypadku interfejsów API generacyjnych sztucznej inteligencji:
  • 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.
    • Zdefiniuj timeout w zasadzie forward-request i staraj się o najkrótszą akceptowalną wartość.
    • Ogranicz liczbę równoległych połączeń zaplecza za pomocą zasad limit-concurrency.
  • 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 znaków wieloznacznych (*) w zasadach CORS.
  • Platforma Azure ma zarówno ochronę na poziomie platformy, jak i rozszerzoną ochronę przed atakami DDoS (rozproszonej odmowy 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 Azure Application Gateway, Azure Front Door lub Azure DDoS Protection. W przypadku korzystania z zasad zapory aplikacji internetowej z usługą Azure Application Gateway lub Azure Front Door rozważ użycie Microsoft_BotManagerRuleSet_1.0.

Niewłaściwa autoryzacja funkcji

Złożone zasady kontroli dostępu z różnymi hierarchiami, grupami i rolami oraz niejasne rozdzielenie funkcji administracyjnych i zwykłych 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: API5:2023 Broken function level authorization

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 zasady validate-azure-ad-token, aby zweryfikować tokeny Microsoft Entra. Określ wszystkie wymagane roszczenia i, jeśli ma to zastosowanie, określ autoryzowane zastosowania.
    • W przypadku sprawdzania poprawności tokenów niewystawionych przez Microsoft Entra zdefiniuj zasady validate-jwt i wymuś wymagane roszczenia tokenu. Jeśli to możliwe, ustaw wymagany czas wygaśnięcia.
    • Jeśli to możliwe, użyj zaszyfrowanych tokenów lub wymień określone aplikacje 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 przed publicznym Internetem. Dowiedz się więcej o opcjach sieci wirtualnej za pomocą usługi API Management.
  • Nie należy definiować operacji interfejsu API z symbolem wieloznacznym (czyli interfejsów API „catch-all” z *  jako ścieżką). Upewnij się, że usługa API Management obsługuje tylko żądania kierowane do jawnie zdefiniowanych punktów końcowych, a żądania do niezdefiniowanych punktów końcowych są odrzucane.
  • Nie publikuj interfejsów API z produktami publicznymi, które nie wymagają subskrypcji.
  • Jeśli są znane adresy IP klientów, użyj zasad ip-filter, aby zezwolić na ruch tylko z autoryzowanych adresów IP.
  • Użyj zasad validate-client-certificate, aby wymusić, by certyfikat przedstawiony przez klienta w wystąpieniu usługi API Management był zgodny z określonymi regułami walidacji i zastrzeżeniami.

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

Interfejsy API mogą uwidaczniać szeroką gamę funkcji aplikacji korzystającej z API. 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: API6:2023 Nieograniczony dostęp do poufnych przepływów biznesowych

Zalecenia

  • Ogranicz lub zablokuj dostęp na podstawie fingerprintów klienta. Na przykład użyj zasady return-response z zasadą choose, 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 zasady ip-filter, 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 zasady rate-limit-by-key, aby ograniczyć wzrost użycia interfejsu API na podstawie tożsamości użytkownika, adresu IP lub innej wartości.
  • Umieść usługę API Management przed usługą Azure Application Gateway lub Azure DDoS Protection w celu wykrywania i blokowania ruchu botów.

Fałszowanie żądań po stronie serwera

Podatność typu SSRF 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 odpowiedniej walidacji.

Więcej informacji o tym zagrożeniu: API7:2023 Fałszowanie żądań po stronie serwera

Zalecenia

  • Jeśli to możliwe, nie używaj adresów URL podanych w ładunkach danych klienta, na przykład jako parametrów dla adresów URL zaplecza, zasad send-request ani rewrite-url.
  • Jeśli 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 za pomocą zasad w API Management, takich jak zasada choose i wyrażenia zasad.
  • Zdefiniuj atrybut timeout w zasadach forward-request i send-request.
  • Weryfikowanie i oczyszczanie danych żądania i odpowiedzi przy użyciu zasad walidacji. W razie potrzeby użyj zasad set-body, aby przetworzyć odpowiedź i uniknąć zwracania nieprzetworzonych danych.
  • Użyj sieci prywatnych, 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ć podatności wynikające z błędnej konfiguracji zabezpieczeń, takie jak:

  • Brak utwardzania zabezpieczeń
  • Niepotrzebnie włączone funkcje
  • Połączenia sieciowe niepotrzebnie otwarte na internet
  • Używanie słabych protokołów lub szyfrów

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

Zalecenia

  • Poprawnie skonfiguruj 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 inspekcjonować i wymuszać przy użyciu usługi Azure Policy.
  • Rozważ wdrożenie usługi API Management za prywatnym punktem końcowym lub dołączenie jej 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 odwrotnego 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ć obecność i ważność tokenu, zanim dotrze on do zaplecza. Automatycznie sprawdź czas wygaśnięcia tokenu, podpis tokenu i wystawcę. Wymuś claimy, odbiorców, wygaśnięcie tokenu i podpis tokenu za pomocą ustawień zasad. Jeśli używasz Microsoft Entra, zasada validate-azure-ad-token zapewnia bardziej kompleksowy i łatwiejszy sposób weryfikowania tokenów zabezpieczających.
    • Skonfiguruj zasady MECHANIZMU CORS i nie używaj symbolu wieloznacznego * dla żadnej opcji konfiguracji. Zamiast tego jawnie wymień 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 API Management znajduje się poza granicą sieci, weryfikacja adresów IP klienta jest nadal możliwa przy użyciu zasady ograniczania adresów IP wywołujących. Upewnij się, że używa allowlisty, a nie blocklisty.
    • Jeśli certyfikaty klienta są używane między wywołującym a usługą API Management, użyj zasady validate-client-certificate. Upewnij się, że atrybuty validate-revocation, validate-trust, validate-not-before i validate-not-after są wszystkie ustawione na true.
  • Certyfikaty klienta (wzajemny protokół TLS) można również stosować między usługą API Management i zapleczem. Backend powinien:
    • Skonfiguruj poświadczenia 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 polityki validate-graphQL-request. Upewnij się, że element authorization oraz atrybuty max-size i max-depth zostały ustawione.
  • Nie przechowuj tajnych danych w plikach zasad ani w systemie kontroli wersji. Zawsze używaj usługi API Management wartości nazwanych lub pobieraj wpisy tajne w czasie wykonywania przy użyciu niestandardowych wyrażeń zasad policy. Nazwane wartości powinny być zintegrowane z usługą Azure Key Vault lub zaszyfrowane w usłudze API Management, oznaczając je jako „tajne”. Nigdy nie przechowuj sekretów w postaci zwykłego tekstu w nazwanych wartościach.
  • Publikuj interfejsy API za pośrednictwem produktów, które wymagają subskrypcji. Nie używaj produktów bez subskrypcji, 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 bramy hostowanej samodzielnie upewnij się, że istnieje proces okresowy aktualizowania obrazu do najnowszej wersji.
  • Przedstaw usługi zaplecza jako encje backendowe. Skonfiguruj poświadczenia autoryzacji, walidację łańcucha certyfikatów i walidację nazwy certyfikatu, jeśli ma to zastosowanie.
  • Upewnij się, że backend'y są chronione przed atakami przechodzenia po ścieżkach (przechodzenie po katalogach). Zarządzanie API może przekazywać żądania zawierające ..%2f lub podobne ukryte sekwencje przechodzenia (na przykład %2e%2e lub ..;) w ścieżce URL do backendu. Jeśli backend odkoduje je do ../, może być podatny na atak typu path traversal. Możesz także zastosować politykę w Zarządzaniu API, która wykrywa i blokuje żądania zawierające takie sekwencje na ścieżce.
  • 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ę hostować samodzielnie portal dla deweloperów, upewnij się, że istnieje proces okresowego aktualizowania portalu hostowanego samodzielnie do najnowszej wersji. Aktualizacje dla domyślnie zarządzanej wersji są automatyczne.
    • Użyj identyfikatora Entra firmy Microsoft lub identyfikatora zewnętrznego firmy Microsoft, aby zarejestrować się i zalogować użytkownika. Wyłącz domyślne uwierzytelnianie nazwą użytkownika i 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ść zmian zawartości i konfiguracji usługi API Management oraz zminimalizować błędy ludzkie.
  • Nie używaj żadnych przestarzałych funkcji.

Nieprawidłowe zarządzanie zapasami

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, w których może brakować poprawek zabezpieczeń

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

Zalecenia

  • Użyj dobrze zdefiniowanej specyfikacji OpenAPI jako źródła do importowania interfejsów API REST. Specyfikacja umożliwia enkapsulację definicji interfejsu API, w tym metadanych samodokumentujących.
  • 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ą powierzchnię ataku i utrudniają rozwijanie interfejsu API.
  • Użyj poprawek i wersji w usłudze API Management, aby zarządzać zmianami interfejsu API. Mieć silną strategię wersjonowania backendu i przyjąć 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.
  • Oddziel środowiska (takie jak deweloperskie, testowe i produkcyjne) 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 praktyk 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.
  • Odkrywaj nieudokumentowane lub niezarządzane interfejsy API i udostępniaj je za pośrednictwem usługi API Management w celu uzyskania lepszej kontroli.
  • Użyj Azure API Center, aby utrzymać kompleksowy, scentralizowany spis 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 downstream 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 sanityzacji 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: API10:2023 Niebezpieczne korzystanie z 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 zasadą send-request 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 wymuszanie konfiguracji 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 zużycia za pomocą zasad rate-limit-by-key i quota-limit-by-key
    • Rejestruj lub blokuj odpowiedzi niezgodne ze specyfikacją interfejsu API przy użyciu zasad validate-content i validate-header
    • Przekształcanie odpowiedzi za pomocą zasady set-body, na przykład w celu usunięcia niepotrzebnych lub poufnych informacji
    • Skonfiguruj limity czasu i ogranicz współbieżność

Powiązane treści

Dowiedz się więcej o:

  • Ostatnia aktualizacja o