Zabezpieczanie wdrożenia serwera MCP Azure

Azure serwer MCP łączy agentów sztucznej inteligencji z usługami Azure, wykonuje narzędzia w Twoim imieniu, a brokerzy uzyskują dostęp do zasobów Azure za pośrednictwem tokenów, które autoryzują każde wywołanie. Ponieważ serwer MCP Azure znajduje się między agentami a zasobami w chmurze, należy chronić sam serwer MCP Azure, tokeny, które autoryzuje dostęp, oraz dane wejściowe i wyjściowe narzędzia, które przepływają przez agentów.

Ten artykuł zawiera wskazówki dotyczące najlepszego zabezpieczania wdrożenia serwera MCP Azure.

Uwierzytelnianie i autoryzacja

Serwer Azure MCP używa Microsoft Entra ID za pośrednictwem biblioteki Azure Identity do uwierzytelniania wywołujących. Specyfikacja autoryzacji MCP wymaga protokołu OAuth 2.1, dlatego należy traktować serwer Azure MCP jako serwer zasobów OAuth 2.1. Klienci muszą używać klucza PKCE (klucza sprawdzającego kod Exchange) podczas wykonywania przepływów kodu autoryzacji. Zastosuj następujące rozwiązania:

  • Zweryfikuj każdy token autoryzacji. Przed zezwoleniem na wykonywanie narzędzia sprawdź wystawcę, odbiorców i wygaśnięcie dla każdego przychodzącego tokenu autoryzacji. Nie ufaj tokenom, które nie mają wymaganych oświadczeń lub zostały wystawione dla innego zasobu.

  • Wiązanie tokenów autoryzacji z zamierzonymi odbiorcami. Używaj tokenów powiązanych z odbiorcami, aby nie można było odtworzyć tokenu wystawionego dla jednej usługi.

  • Wymuszanie ścisłego dopasowywania identyfikatora URI przekierowania i zgody na klienta. W przypadku przepływów kodu autoryzacji zezwalaj tylko na wstępne wyrejestrowanie, dokładne identyfikatory URI przekierowania i wymaganie zgody na klienta, więc przechwycony kod autoryzacji nie może zostać zrealizowany przez innego klienta.

  • Postępuj zgodnie z kontrolą dostępu opartą na rolach z najniższymi uprawnieniami. Przyznaj każdemu obiektowi wywołującym tylko role kontroli dostępu opartej na rolach Azure wymagane do jego zadania. Serwer MCP Azure odzwierciedla uprawnienia subskrypcji Azure — osoby wywołujące, które mają szeroki dostęp do subskrypcji, mogą wywoływać szeroki zestaw narzędzi. Zakres przypisań ról tak wąsko, jak to możliwe. Włącz tylko narzędzia, których potrzebuje każdy obiekt wywołujący, ponieważ każde dostępne narzędzie dodaje je do obszaru ataków.

  • Preferuj tożsamości obciążeń. W scenariuszach agentów użyj tożsamości zarządzanych lub tożsamości obciążeń, a nie długoterminowych wpisów tajnych lub poświadczeń udostępnionych. Gdy poświadczenia statyczne są nieuniknione — na przykład klucze interfejsu API dla usług innych firm, które nie obsługują tożsamości obciążenia , przechowuj je w Azure Key Vault i odwołują się do nich z konfiguracji wdrożenia. Nigdy nie przechowuj poświadczeń w kodzie źródłowym lub plikach konfiguracji zwykłego tekstu i obracaj je zgodnie z regularnym harmonogramem.

  • Unikaj dezorientowanego wzorca zastępcy. Określ zakres Azure tożsamości Azure serwera MCP i uprawnień do minimum, które musi działać. Nie pozwól, aby serwer działał jako zastępca, który nadaje jej szerokie uprawnienia do modułu wywołującego o niższych uprawnieniach: oddzielić tożsamość wykonywania serwera od autoryzacji obiektu wywołującego i wymusić kontrole uprawnień poszczególnych wywołań, a nie polegać wyłącznie na własnych poświadczeniach serwera.

Zdalna ochrona serwera MCP Azure

Podczas wdrażania Azure serwera MCP jako zdalnego serwera self-hosted rozważ umieszczenie go za Azure API Management (APIM) jako bramy wymuszania:

  • Umieść Azure serwer MCP za bramą wymuszania. Usługa APIM może zweryfikować Entra ID tokeny, zanim żądania dotrą do Azure serwera MCP, co eliminuje potrzebę sprawdzenia tokenów przez kod aplikacji.

  • Stosowanie zasad bramy na potrzeby ograniczania szybkości i inspekcji. Użyj zasad usługi APIM, aby ograniczyć częstotliwość wysyłania żądań przez osoby wywołujące, ograniczać dozwolone ścieżki narzędzi i rejestrować każde żądanie do celów inspekcji.

  • Scentralizowana kontrola dostępu w jednym punkcie dławiku. Brama zapewnia pojedynczy punkt kontroli dostępu i wglądu w wiele podrzędnych narzędzi MCP.

Chroń punkt końcowy, z który Azure klientów serwera MCP. Zastąpiony lub sfałszowany adres URL może odbierać żądania wykonywania narzędzi i uwidaczniać poświadczenia lub dane zasobów Azure. Aby zmniejszyć to ryzyko:

  • Połącz się tylko z zaufanymi punktami końcowymi serwera MCP Azure. Używaj tylko punktów końcowych aprowizowania lub uwidacznianych przez zespół za pośrednictwem usługi APIM. Nie należy uzyskiwać Azure adresu URL serwera MCP z dostarczonych przez użytkownika danych wejściowych lub nieuwierzytelnionych odpowiedzi odnajdywania.

  • Sprawdź certyfikat TLS serwera MCP Azure. Upewnij się, że punkt końcowy jest zgodny z oczekiwanym hostem. W przypadku korzystania z usługi APIM należy kierować klientów za pośrednictwem bramy, aby punkt końcowy kopii zapasowej nie mógł być przekierowywany w trybie dyskretnym.

  • Nie można zamknąć w przypadku błędów certyfikatu. Traktuj niezweryfikowany lub nierozpoznany certyfikat serwera MCP Azure jako błąd połączenia, a nie ostrzeżenie o obejściu.

Aby uzyskać informacje o opcjach samoobsługowego hostingu, zobacz Wdrażanie własnego serwera Azure MCP.

Lokalne wzmacnianie zabezpieczeń wdrożenia

Lokalny serwer Azure MCP działa w środowisku dewelopera na potrzeby programowania. Ponieważ może ona działać z tożsamością Azure, przed połączeniem agenta z zasobami Azure sprawdź, do czego może uzyskiwać dostęp zalogowane konto:

  • Przejrzyj uprawnienia Azure. Sprawdź role RBAC Azure przypisane do konta dewelopera i usuń uprawnienia szerokiej subskrypcji lub grupy zarządzania, które nie są potrzebne do zadania.

  • Ogranicz dostęp lokalny. Uruchom lokalny serwer Azure MCP z zaufanej stacji roboczej lub kontenera i nie udostępniaj lokalnego punktu końcowego niezaufanym sieciom ani innym użytkownikom na maszynie.

  • Zachowaj bieżący serwer lokalny. Użyj bieżących pakietów Azure serwera MCP i poprawek zależności, szczególnie przed rozpoczęciem testowania pod kątem zasobów nieprodukcyjnych Azure.

  • Lokalne wykonywanie piaskownicy. Uruchom lokalny serwer Azure MCP w kontenerze lub piaskownicy z ograniczonym systemem plików i dostępem do sieci, a następnie zachowaj poprawkę łańcucha narzędzi, aby ograniczyć wpływ wstrzykiwania poleceń i przechodzenia ścieżki, gdy narzędzia duplikuje podprocesy.

Nie używaj lokalnego serwera Azure MCP do obsługi danych produkcyjnych ani poświadczeń produkcyjnych.

Zatrucie narzędzi i wstrzyknięcie monitu

Opisy narzędzi MCP i odpowiedzi narzędzi to dane wejściowe kontekstu agenta. Jeśli metadane narzędzia lub dane wyjściowe narzędzia są złośliwe, może to mieć wpływ na agenta, który ma dostęp do narzędzi Azure MCP Server i Azure uprawnień za nimi.

Aby zmniejszyć to ryzyko dla wdrożeń Azure MCP Server:

  • Preferuj oficjalny Microsoft utrzymywany Azure MCP Server. Użyj serwera Azure MCP pierwszej firmy dla usług Azure zamiast niezweryfikowanego serwera, który uwidacznia podobne narzędzia Azure. Traktuj zmiany schematu narzędzi jako zmiany zależności, które wymagają przeglądu.

  • Ufaj, ale weryfikuj kontekst narzędzia. Traktuj opisy narzędzi i odpowiedzi jako niezaufane dane wejściowe agenta. Przejrzyj definicje narzędzi przed użyciem środowiska produkcyjnego i zweryfikuj lub odczyść dane, które odpowiedzi narzędzi są przekazywane z powrotem do kontekstu agenta.

  • Definicje narzędzi change-control. Przejrzyj i przypnij znane dobre schematy narzędzi i opisy oraz wymagaj ponownego zatwierdzenia przed zastosowaniem zaktualizowanych metadanych narzędzia, dzięki czemu serwer nie może dyskretnie zmienić zachowania po zatwierdzeniu (łańcuch dostaw "ściąganie dywanu").

  • Użyj Azure mechanizmów kontroli zabezpieczeń, gdzie pasują one do twojej architektury. Oceń kontrolki w Microsoft mechanizmach kontroli zabezpieczeń, aby sprawdzić kontekst agenta, wykrywać poufne przepływy danych i monitorować obciążenia Azure sztucznej inteligencji. Przed rozpoczęciem polegania na niej w środowisku produkcyjnym sprawdź każdą ścieżkę integracji.

Zaufanie serwera MCP innej firmy

Wiele środowisk deweloperskich uruchamia jednocześnie wiele serwerów MCP. Aby Azure pracy, preferuj oficjalny Microsoft utrzymywany Azure MCP Server nad alternatywami społeczności dla usług Azure.

W przypadku dodania serwera MCP innej firmy obok Azure serwera MCP:

  • Sprawdź wydawcę i ścieżkę aktualizacji. Używaj serwerów od zaufanych wydawców z kontaktem z zabezpieczeniami publicznymi. Przejrzyj dzienniki zmian i aktualizacje pakietów przed zezwoleniem serwerowi innej firmy na środowisko agenta, które może również uzyskiwać dostęp do Azure narzędzi serwera MCP.

  • Zachowaj oddzielne konteksty poświadczeń. Nie pozwól, aby niezweryfikowany serwer współużytkował poświadczenia, system plików lub dostęp sieciowy używany przez serwer Azure MCP. Uruchamianie niezaufanych serwerów z najniższymi uprawnieniami w izolowanym środowisku.

  • Przejrzyj narzędzia w całym kontekście agenta. Złośliwy serwer może używać opisów narzędzi, aby wpływać na zachowanie agenta w stosunku do innych zaufanych serwerów w tym samym kontekście, w tym Azure serwera MCP. Przeprowadź inspekcję opisów narzędzi dla każdego skonfigurowanego serwera, a nie tylko narzędzi Azure.

Nadzór i monitorowanie

Śledź, które Azure wystąpienia serwera MCP działają w danym środowisku, i monitoruj ich aktywność:

  • Spis zatwierdzonych serwerów. Zachowaj znany dobry punkt odniesienia zarejestrowanych Azure punktów końcowych serwera MCP, na przykład przy użyciu Azure Centrum interfejsu API, dzięki czemu można wykrywać niezarejestrowane serwery "w tle", które znajdują się poza ładem.

  • Monitorowanie aktywności i zachowywanie dowodów. Skoreluj działanie serwera Azure MCP w Microsoft Sentinel i zachowaj dzienniki inspekcji Microsoft Purview, aby umożliwić badanie podejrzanych wywołań narzędzi.

Microsoft mechanizmów kontroli zabezpieczeń

Skorzystaj z poniższych Microsoft usług zabezpieczeń, aby dodać szczegółowe zabezpieczenia dla obciążeń Azure serwera MCP. Zastosowanie każdej kontrolki do określonego wdrożenia zależy od architektury. Oceń każdą kontrolkę w kontekście własnego środowiska:

  • Sprawdź kontekst agenta za pomocą osłon monitu. Użyj Bezpieczeństwo zawartości platformy Azure AI Monituj osłony, aby sprawdzić zawartość wchodzącą w kontekst agenta — w tym opisy narzędzi i dane wyjściowe narzędzi — i wykryć potencjalne próby wstrzyknięcia monitu. Rozważ integrację funkcji Prompt Shields w potoku agenta, gdy używasz dynamicznie załadowanych metadanych narzędzia. Aby uzyskać więcej informacji, zobacz Monitowanie osłon.

  • Wykrywanie poufnych przepływów danych za pomocą funkcji DLP usługi Purview. Jeśli obciążenie jest jawnie zintegrowane z Microsoft Purview, użyj zasad ochrony przed utratą danych usługi Purview, aby ułatwić wykrywanie i flagowanie poufnych danych w przepływach danych skojarzonych z agentami. Pokrycie dowolnych parametrów wywołania narzędzi nie jest automatyczne — zależy to od architektury wdrożenia i łączników usługi Purview używanych przez obciążenie. Sprawdź, czy określona ścieżka integracji obsługuje wymagane kontrolki przed użyciem DLP dla obciążeń agenta. Aby uzyskać więcej informacji, zobacz dokumentację usługi Microsoft Purview.

  • Monitorowanie obciążeń sztucznej inteligencji przy użyciu Defender dla Chmury. Użyj Microsoft Defender dla Chmury ochrony przed zagrożeniami sztucznej inteligencji na potrzeby wykrywania zagrożeń środowiska uruchomieniowego w obciążeniach sztucznej inteligencji, w tym alertów dotyczących podejrzanych działań w interfejsie API Azure OpenAI i Azure wywołania interfejsu API wnioskowania modelu sztucznej inteligencji. Pokrycie nie jest automatycznie rozszerzane na dowolne dane wyjściowe narzędzia MCP — dotyczy to warstwy usługi Azure AI w architekturze. Aby uzyskać więcej informacji, zobacz Ochrona przed zagrożeniami w sztucznej inteligencji.

Note

Wymienione wcześniej mechanizmy kontroli to ogólne Azure usługi zabezpieczeń. Przed włączeniem tej ścieżki w środowisku produkcyjnym sprawdź, czy ścieżka integracji każdej kontrolki jest obsługiwana dla określonej architektury wdrażania serwera MCP Azure.

Treści powiązane

  • Last updated on