Share via

Rekomendacje w celu wyeliminowania zagrożeń zabezpieczeń interfejsu API OWASP Top 10 przy użyciu usługi API Management

  • Artykuł

DOTYCZY: Wszystkie warstwy usługi API Management

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ówimy zalecenia dotyczące używania usługi Azure API Management w celu wyeliminowania 10 najważniejszych zagrożeń interfejsu API zidentyfikowanych przez program OWASP.

Uwaga

Oprócz przestrzegania zaleceń opisanych w tym artykule można włączyć usługę Defender dla interfejsów API, możliwość Microsoft Defender dla Chmury, na potrzeby szczegółowych informacji o zabezpieczeniach interfejsu API, zaleceń i wykrywania zagrożeń. Dowiedz się więcej o korzystaniu z usługi Defender dla interfejsów API za pomocą usługi API Management

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:2019

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 wymusij autoryzację na poziomie obiektu za pomocą zasad walidowania żądań GraphQL przy użyciu authorize elementu .

Przerwane uwierzytelnianie użytkownika

Mechanizmy uwierzytelniania są często implementowane niepoprawnie lub brakuje ich, co umożliwia atakującym wykorzystanie wad implementacji w celu uzyskania dostępu do danych.

Więcej informacji o tym zagrożeniu: Interfejs API2:2019 — przerwane uwierzytelnianie użytkowników

Zalecenia

Użyj usługi API Management do uwierzytelniania i autoryzacji użytkowników:

  • Uwierzytelnianie — usługa API Management obsługuje następujące metody uwierzytelniania:

    • Podstawowe zasady uwierzytelniania — poświadczenia nazwy użytkownika i hasła.

    • Klucz subskrypcji — klucz subskrypcji zapewnia podobny poziom zabezpieczeń jako uwierzytelnianie podstawowe i może nie być wystarczający sam. Jeśli klucz subskrypcji zostanie naruszony, osoba atakująca może uzyskać nieograniczony dostęp do systemu.

    • Zasady certyfikatów klienta — używanie certyfikatów klienta jest bezpieczniejsze niż podstawowe poświadczenia lub klucz subskrypcji, ale nie zezwala na elastyczność zapewnianą przez protokoły autoryzacji oparte na tokenach, takie jak OAuth 2.0.

  • Autoryzacja — usługa API Management obsługuje weryfikowanie zasad JWT w celu sprawdzenia poprawności przychodzącego tokenu dostępu OAuth 2.0 JWT na podstawie informacji uzyskanych z punktu końcowego metadanych dostawcy tożsamości OAuth. Skonfiguruj zasady, aby sprawdzać odpowiednie oświadczenia tokenu, odbiorców i czas wygaśnięcia. Dowiedz się więcej o ochronie interfejsu API przy użyciu autoryzacji OAuth 2.0 i identyfikatora Entra firmy Microsoft.

Więcej zaleceń:

  • Użyj zasad w usłudze API Management, aby zwiększyć bezpieczeństwo. Na przykład ograniczanie szybkości wywołań spowalnia złych aktorów przy użyciu ataków siłowych w celu naruszenia poświadczeń.

  • Interfejsy API powinny używać protokołu TLS/SSL (zabezpieczeń transportu) w celu ochrony poświadczeń lub tokenów. Poświadczenia i tokeny powinny być wysyłane w nagłówkach żądań, a nie jako parametry zapytania.

  • W portalu deweloperów usługi API Management skonfiguruj identyfikator entra firmy Microsoft lub usługę Azure Active Directory B2C jako dostawcę tożsamości, aby zwiększyć bezpieczeństwo konta. Portal deweloperów używa capTCHA do eliminowania ataków siłowych.

Nadmierne narażenie na dane

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.

Zły aktor może próbować uzyskać bezpośredni dostęp do interfejsu API (na przykład przez odtworzenie prawidłowego żądania) lub wąchanie ruchu między serwerem a interfejsem API. Analiza akcji interfejsu API i dostępnych danych może spowodować uzyskanie poufnych danych osobom atakującym, które nie są udostępniane lub używane przez aplikację frontonu.

Więcej informacji o tym zagrożeniu: Interfejs API3:2019 Nadmierne narażenie na dane

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:

    • Poprawki do bezproblemowego kontrolowania zmian niezwiązanych, na przykład dodawania pola do interfejsu. Możesz używać poprawek wraz z implementacją obsługi wersji w zapleczu.

    • Wersje zmian powodujących niezgodność, na przykład usunięcie pola z interfejsu.

  • 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. Na przykład usuń niepotrzebne właściwości JSON z treści odpowiedzi.

  • Walidacja zawartości odpowiedzi w usłudze API Management może służyć ze schematem XML lub JSON do blokowania odpowiedzi z nieudokumentowanych właściwościami lub nieprawidłowymi wartościami. Zasady obsługują również blokowanie odpowiedzi przekraczających określony rozmiar.

  • Użyj zasad weryfikowania kodu stanu, aby zablokować odpowiedzi z błędami niezdefiniowanym w schemacie interfejsu API.

  • Użyj zasad weryfikowania nagłówków, 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 nagłówka zestawu.

  • W przypadku scenariuszy graphQL użyj zasad weryfikowania żądań GraphQL, aby zweryfikować żądania GraphQL, autoryzować dostęp do określonych ścieżek zapytań i ograniczyć rozmiar odpowiedzi.

Brak zasobów i ograniczanie szybkości

Brak ograniczania szybkości może prowadzić do eksfiltracji danych lub pomyślnych ataków DDoS na usługi zaplecza, powodując awarię dla wszystkich użytkowników.

Więcej informacji na temat tego zagrożenia: INTERFEJS API4:2019 Brak zasobów i ograniczanie szybkości

Zalecenia

  • Użyj zasad limitu szybkości (krótkoterminowego) i limitu przydziału (długoterminowego), aby kontrolować dozwoloną liczbę wywołań interfejsu API lub przepustowość na użytkownika.

  • Zdefiniuj ścisłe definicje obiektów żądań i ich właściwości w definicji interfejsu OpenAPI. Na przykład zdefiniuj maksymalną wartość dla liczb całkowitych stronicowania, maxLength i wyrażenia regularnego (regex) dla ciągów. Wymuś te schematy za pomocą zasad weryfikowania zawartości i weryfikowania parametrów w usłudze API Management.

  • Wymuszanie maksymalnego rozmiaru żądania przy użyciu zasad weryfikowania zawartości .

  • 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.

  • Wymuszanie uwierzytelniania dla wywołań interfejsu API (zobacz Przerwane uwierzytelnianie użytkownika). Odwoływanie dostępu dla obraźliwych użytkowników. Na przykład zdezaktywuj klucz subskrypcji, zablokuj adres IP przy użyciu zasad ograniczeń adresów IP obiektu wywołującego lub odrzuć żądania dla określonego oświadczenia użytkownika z tokenu JWT.

  • 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.

  • 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.

  • Usługa API Management może chronić usługi zaplecza przed atakami DDoS, ale może być podatna na ataki. Wdróż usługę ochrony botów przed usługą API Management (na przykład aplikacja systemu Azure Gateway, Azure Front Door lub Azure DDoS Protection), aby lepiej chronić przed atakami DDoS. W przypadku korzystania z 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:2019

Zalecenia

  • Domyślnie chroń wszystkie punkty końcowe interfejsu API w usłudze API Management przy użyciu kluczy subskrypcji.

  • Zdefiniuj zasady weryfikacji JWT i wymuś wymagane oświadczenia tokenu. Jeśli niektóre operacje wymagają bardziej rygorystycznego wymuszania oświadczeń, zdefiniuj dodatkowe validate-jwt zasady tylko dla tych operacji.

  • 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.

Przypisanie masowe

Jeśli interfejs API oferuje więcej pól niż klient wymaga wykonania danej akcji, osoba atakująca może wstrzyknąć nadmierne właściwości w celu wykonania nieautoryzowanych operacji na danych. Osoby atakujące mogą odnaleźć nieudokumentowane właściwości, sprawdzając format żądań i odpowiedzi lub innych interfejsów API lub zgadując je. Ta luka w zabezpieczeniach jest szczególnie stosowana, jeśli nie używasz silnie typiowanych języków programowania.

Więcej informacji o tym zagrożeniu: przypisywanie zbiorcze interfejsu API6:2019

Zalecenia

  • Zewnętrzne interfejsy API powinny być oddzielone od wewnętrznej implementacji danych. Unikaj wiązania kontraktów interfejsu API bezpośrednio z kontraktami danych w usługach zaplecza. Przejrzyj często projekt interfejsu API i usuwaj starsze właściwości i usuwaj je przy użyciu obsługi wersji w usłudze API Management.

  • Dokładnie zdefiniuj kontrakty XML i JSON w schemacie interfejsu API oraz użyj zasad weryfikowania zawartości i weryfikowania parametrów w celu blokowania żądań i odpowiedzi przy użyciu właściwości nieudokumentowanych. 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.

  • Jeśli nie można zmienić interfejsu zaplecza, użyj zasad przekształcania, aby przepisać ładunki żądań i odpowiedzi oraz rozdzielić kontrakty interfejsu API z kontraktów zaplecza. Na przykład zamaskuj lub przefiltruj dane lub usuń niepotrzebne właściwości JSON.

Błędna konfiguracja zabezpieczeń

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

  • Brak wzmacniania zabezpieczeń
  • Niepotrzebne funkcje włączone
  • Połączenia sieciowe niepotrzebnie otwarte dla Internetu
  • Używanie słabych protokołów lub szyfrowania
  • Inne ustawienia lub punkty końcowe, które mogą zezwalać na nieautoryzowany dostęp do systemu

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

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.

  • 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 weryfikacji JWT, aby sprawdzić istnienie i ważność tokenu JWT 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.

    • 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 na prevent wartość 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 weryfikowania certyfikatu klienta. 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 weryfikowania żądań GraphQL. Upewnij się, że authorization element i max-depthmax-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ą 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.

  • Integracja usługi Key Vault umożliwia zarządzanie wszystkimi certyfikatami — pozwala to na scentralizowanie zarządzania certyfikatami i ułatwia wykonywanie zadań zarządzania operacjami, takich jak odnawianie certyfikatów lub odwoływanie certyfikatów.

  • 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.

  • 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 dla 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.

Wstrzyknięcie

Każdy punkt końcowy akceptujący dane użytkownika jest potencjalnie narażony na wykorzystanie iniekcji. Przykłady obejmują, ale nie są ograniczone do następujących elementów:

  • Iniekcja poleceń, gdzie zły aktor próbuje zmienić żądanie interfejsu API w celu wykonania poleceń w systemie operacyjnym hostowania interfejsu API

  • Wstrzyknięcie kodu SQL, w którym nieprawidłowy aktor próbuje zmienić żądanie interfejsu API w celu wykonania poleceń i zapytań względem bazy danych, od którego zależy interfejs API

Więcej informacji o tym zagrożeniu: wstrzyknięcie interfejsu API8:2019

Zalecenia

  • Nowoczesne zasady zapory aplikacji internetowej (WAF) obejmują wiele typowych luk w zabezpieczeniach polegających na wstrzyknięciu. Chociaż usługa API Management nie ma wbudowanego składnika zapory aplikacji internetowej, zdecydowanie zaleca się wdrożenie nadrzędnej zapory aplikacji internetowej (z przodu) wystąpienia usługi API Management. Na przykład użyj aplikacja systemu Azure Gateway lub Azure Front Door.

    Ważne

    Upewnij się, że zły aktor nie może pominąć bramy obsługującej zaporę aplikacji internetowej i połączyć się bezpośrednio z bramą usługi API Management lub interfejsem API zaplecza. Możliwe środki zaradcze obejmują: listy ACL sieci przy użyciu zasad usługi API Management w celu ograniczenia ruchu przychodzącego przez adres IP klienta, usunięcie dostępu publicznego, jeśli nie jest to wymagane, oraz uwierzytelnianie certyfikatu klienta (nazywane również wzajemnym protokołem TLS lub mTLS).

  • Użyj zasad weryfikacji schematu i parametrów, jeśli ma to zastosowanie, aby jeszcze bardziej ograniczyć i zweryfikować żądanie przed dotarciem do usługi interfejsu API zaplecza.

    Schemat dostarczony z definicją interfejsu API powinien mieć ograniczenie wzorca regularnego stosowane do pól narażonych. Każdy wyrażeń regularnych należy przetestować, aby upewnić się, że ogranicza to pole wystarczająco, aby ograniczyć typowe próby wstrzyknięcia.

Niewłaściwe zarządzanie zasobami

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:2019 Niewłaściwe zarządzanie zasobami

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ć punktami końcowymi interfejsu API i kontrolować je. 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.

  • Użyj wystąpienia usługi API Management dla każdego środowiska (takiego jak programowanie, testowanie i produkcja). Upewnij się, że każde wystąpienie usługi API Management łączy się ze swoimi 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.

  • 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 wbudowanego 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.

Niewystarczające rejestrowanie i monitorowanie

Niewystarczające rejestrowanie i monitorowanie, w połączeniu z brakującą lub nieskuteczną integracją z reagowaniem na zdarzenia, umożliwia atakującym dalsze systemy ataków, utrzymywanie trwałości, przestawienie się na więcej systemów w celu manipulowania nimi i wyodrębnianie lub niszczenie danych. Większość badań naruszenia zabezpieczeń pokazuje, że czas wykrywania naruszenia wynosi ponad 200 dni, zazwyczaj wykrywany przez strony zewnętrzne, a nie wewnętrzne procesy lub monitorowanie.

Więcej informacji o tym zagrożeniu: Interfejs API10:2019 Niewystarczające rejestrowanie i monitorowanie

Zalecenia

Następne kroki

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