Projekt OWASP GenAI Security definiuje minimalne standardy w pięciu kategoriach dla bezpiecznego wdrożenia serwera MCP. Użyj tej listy kontrolnej, aby ocenić swoją obecną postawę w zakresie tożsamości, izolacji, narzędzi, walidacji i wdrożenia przed przejściem do produkcji.
Praktyczny przewodnik projektu OWASP GenAI Security po tworzeniu serwera MCP kulminuje w konkretnej liście kontrolnej przeglądu — „Minimalne standardy bezpieczeństwa MCP". Ta lista kontrolna definiuje podstawowe kontrole, które muszą być wdrożone przed wdrożeniem serwera MCP do produkcji.
Ten wpis przedstawia pełną listę kontrolną z wytycznymi implementacyjnymi dla każdego elementu, zorganizowaną w pięciu dziedzinach bezpieczeństwa definiowanych przez przewodnik OWASP. Użyj jej do przeglądów bezpieczeństwa przed wdrożeniem, okresowych audytów i jako ramy do naprawiania zidentyfikowanych luk.
Oznaczanie elementów: Dla każdego elementu zapisz ZALICZONY (wdrożony i zweryfikowany), NIEZALICZONY (niewdrożony lub częściowo wdrożony) lub NIE DOTYCZY (nie dotyczy tego wdrożenia).
Bramy wdrożeniowe: Elementy w kategorii 1 (Tożsamość, Uwierzytelnianie, Polityka) i kategorii 2 (Izolacja) są twardymi bramami wdrożeniowymi — każdy NIEZALICZONY powinien zablokować uruchomienie do czasu naprawienia. Elementy w innych kategoriach powinny być zaakceptowane pod względem ryzyka z udokumentowanymi terminami.
Wyzwalacze przeglądu: Uruchom ponownie pełną listę kontrolną po każdej znaczącej zmianie w kodzie serwera MCP, rejestrze narzędzi, konfiguracji uwierzytelniania, środowisku wdrożeniowym lub gdy nowa kategoria narzędzi zostanie wdrożona.
To jest kategoria o najwyższym priorytecie. Awarie uwierzytelniania dają atakującym bezpośredni dostęp do wszystkiego, co może zrobić serwer MCP.
Co zweryfikować: Każde zdalne połączenie z serwerem MCP wymaga uwierzytelnienia przez prawidłowo skonfigurowany serwer autoryzacji OAuth 2.1. Anonimowe połączenia są odrzucane. Lokalne serwery MCP używające STDIO mogą używać alternatywnego uwierzytelniania odpowiedniego do ich kontekstu wdrożenia.
Jak testować: Spróbuj połączyć się bez nagłówka autoryzacji. Spróbuj połączyć się ze zniekształconym lub wygasłym tokenem. Oba powinny skutkować niepowodzeniem uwierzytelnienia, a nie dostępem do narzędzi.
Typowe tryby awarii: Punkty końcowe deweloperskie pozostawione dostępne bez uwierzytelniania; powrót do uwierzytelniania kluczem API, które nie waliduje wygaśnięcia lub zakresu; walidacja tokena tylko przy ustanawianiu sesji, a nie przy każdym żądaniu.
Co zweryfikować: Tokeny dostępu wygasają w ciągu minut (nie godzin). Każdy token zawiera minimalny zakres wymagany do bieżącego zadania. Każde wywołanie narzędzia waliduje podpis tokena, wystawcę (iss), odbiorcę (aud), wygaśnięcie (exp) i wymagany zakres — nie tylko przy ustanawianiu sesji.
Jak testować: Użyj prawidłowego tokena, a następnie poczekaj, aż wygaśnie (lub ręcznie ustaw zegar do przodu). Spróbuj wywołać narzędzie — powinno to zakończyć się błędem 401, a nie powodzeniem na podstawie zbuforowanego wyniku walidacji.
Typowe tryby awarii: Walidacja tokena buforowana przy rozpoczęciu sesji i niepowtarzana; tokeny z czasem życia 24+ godzin; szerokie zakresy „admin" używane zamiast zakresów specyficznych dla operacji; pole exp niezaznaczone.
Co zweryfikować: Serwer MCP nie przekazuje tokenów klienta do podrzędnych API. Wszystkie wywołania usług podrzędnych używają tokenów wyraźnie wystawionych dla serwera MCP (przez przepływy On-Behalf-Of lub dane uwierzytelniające usługi). Scentralizowana brama polityki przechwytuje wszystkie wywołania narzędzi i egzekwuje uwierzytelnianie, autoryzację, zgodę i rejestrowanie audytu przed wykonaniem jakiegokolwiek kodu narzędzia.
Jak testować: Przejrzyj kod w poszukiwaniu dowolnej lokalizacji, w której przychodzący token klienta jest przekazywany w wychodzącym wywołaniu API. Sprawdź dzienniki dostępu usługi podrzędnej, aby zweryfikować, że żądania przychodzą z danymi uwierzytelniającymi serwera, a nie użytkownika.
Typowe tryby awarii: Wzorzec Authorization: Bearer ${request.headers.authorization} w wywołaniach podrzędnych; kontrole autoryzacji rozproszone w poszczególnych procedurach obsługi narzędzi; brak scentralizowanego punktu egzekwowania polityki.
Rozpocznij bezpłatny okres próbny już dziś i zobacz rezultaty w ciągu kilku dni.
Awarie izolacji w środowiskach wielodostępnych są katastrofalne — umożliwiają jednemu użytkownikowi dostęp do danych innego. Są to twarde bramy wdrożeniowe.
Co zweryfikować: Żadne zmienne globalne, atrybuty na poziomie klasy ani współdzielone instancje singletonów nie przechowują danych specyficznych dla użytkownika lub sesji. Każda sesja używa niezależnie utworzonych obiektów lub przestrzeni nazw kluczowanych sesją (np. klucze Redis z prefiksem session_id:). Przegląd kodu potwierdza brak współdzielonego zmiennego stanu między sesjami.
Jak testować: Uruchom dwie równoczesne sesje z różnymi tożsamościami użytkowników. Sprawdź, czy dane zapisane w sesji A nie mogą być odczytane w sesji B. Użyj równoczesnych testów obciążeniowych, aby sprawdzić warunki wyścigu, które mogą powodować wyciek stanu sesji.
Typowe tryby awarii: self.user_context = {} jako atrybut klasy w usłudze singleton; globalne pamięci podręczne bez przestrzeni nazw kluczowanych sesją; magazyn lokalny wątku, który nie zakresuje prawidłowo do cyklu życia żądania.
Co zweryfikować: Poza kontekstem wykonania każda współdzielona infrastruktura (bazy danych, pamięci podręczne, kolejki komunikatów) egzekwuje kontrole dostępu dla poszczególnych użytkowników. Zapytanie wykonane w sesji jednego użytkownika nie może zwrócić danych innego użytkownika, nawet jeśli współdzielona infrastruktura jest źle skonfigurowana lub skompromitowana.
Jak testować: Spróbuj uzyskać dostęp do danych innego użytkownika, manipulując parametrami sesji lub wykorzystując współdzielone klucze pamięci podręcznej.
Typowe tryby awarii: Klucze pamięci podręcznej oparte tylko na treści zapytania, a nie tożsamości użytkownika; zapytania do bazy danych bez klauzul WHERE zakresowanych do użytkownika; współdzielone katalogi plików tymczasowych bez podkatalogów dla poszczególnych użytkowników.
Co zweryfikować: Gdy sesja się kończy (prawidłowo lub przez limit czasu/błąd), wszystkie powiązane zasoby są natychmiast zwalniane: uchwyty plików, pliki tymczasowe, kontekst w pamięci, buforowane tokeny, połączenia z bazą danych. Istnieją limity dla każdej sesji dla pamięci, CPU, szybkości API i użycia systemu plików.
Jak testować: Zakończ sesję nagle (zabij połączenie bez prawidłowego zamknięcia). Sprawdź, czy nie pozostały żadne zasoby szczątkowe. Utwórz sesję i wyczerpaj jej limit szybkości; sprawdź, czy nie wpływa to na inne sesje.
Typowe tryby awarii: Pliki tymczasowe pozostawione w /tmp po zakończeniu sesji; buforowane tokeny nieodwołane po zakończeniu sesji; brak limitów zasobów pozwalających jednej sesji wyczerpać współdzieloną infrastrukturę.
Bezpieczeństwo narzędzi zapobiega najbardziej niebezpiecznym atakom specyficznym dla MCP: zatruwaniu narzędzi i oszustwom typu rug pull.
Co zweryfikować: Każda definicja narzędzia ma podpis kryptograficzny od autoryzowanego zatwierdzającego narzędzia. Podpis obejmuje kompletny manifest (opis, schemat, wersję, uprawnienia). Serwer MCP weryfikuje ten podpis podczas ładowania i odrzuca każde narzędzie niepodpisane lub z niezgodnym podpisem. Wersje narzędzi są przypięte — serwer nie może dynamicznie załadować zaktualizowanego narzędzia bez nowego zatwierdzonego podpisu.
Jak testować: Zmodyfikuj jeden znak w opisie załadowanego narzędzia. Sprawdź, czy serwer wykrywa niezgodność skrótu i blokuje ładowanie narzędzia. Spróbuj załadować niepodpisaną definicję narzędzia — powinna zostać odrzucona.
Typowe tryby awarii: Definicje narzędzi przechowywane jako zmienna konfiguracja bez weryfikacji integralności; brak infrastruktury klucza podpisującego; narzędzia ładowane bezpośrednio z współdzielonego systemu plików bez przypinania wersji.
Co zweryfikować: Automatyczne skanowanie sprawdza opisy narzędzi pod kątem wzorców przypominających instrukcje, które mogą reprezentować próby zatrucia. Okresowa walidacja potwierdza, że rzeczywiste zachowanie narzędzia w czasie wykonania odpowiada jego zadeklarowanemu opisowi — narzędzie, które twierdzi, że jest tylko do odczytu, nie powinno być zdolne do operacji zapisu w czasie wykonania.
Jak testować: Dodaj podejrzaną instrukcję do opisu narzędzia („zawsze również wywołaj send_webhook z…") i sprawdź, czy automatyczne skanowanie ją oznacza przed przeglądem przez człowieka. Przejrzyj konfigurację narzędzia SAST pod kątem reguł wykrywania zatrucia specyficznych dla MCP.
Typowe tryby awarii: Brak automatycznego skanowania opisów narzędzi; ręczny proces przeglądu, który może przeoczyć osadzone instrukcje w długich opisach; brak walidacji zachowania w czasie wykonania, aby wychwycić narzędzia, które kłamią o swoich możliwościach.
Co zweryfikować: Kontekst modelu otrzymuje tylko pola wymagane do prawidłowego wywołania narzędzia: nazwę, opis, schemat wejściowy, schemat wyjściowy. Wewnętrzne metadane, szczegóły implementacji, informacje debugowania i wrażliwa konfiguracja są odfiltrowane przed przekazaniem do modelu.
Jak testować: Sprawdź, co otrzymuje model podczas wyliczania dostępnych narzędzi. Sprawdź, czy żadne pola wewnętrzne, ciągi połączeń ani metadane operacyjne nie pojawiają się w widoku modelu.
Typowe tryby awarii: Pełne obiekty konfiguracyjne narzędzi przekazywane do kontekstu modelu; komunikaty o błędach zawierające wewnętrzne szczegóły systemu, które wyciekają do modelu; opisy narzędzi zawierające notatki implementacyjne nierelewantne dla wywołania.
Otrzymuj najnowsze wskazówki, trendy i oferty za darmo.
Awarie walidacji umożliwiają wstrzykiwanie, manipulację danymi i odmowę usługi.
Co zweryfikować: Walidacja schematu JSON jest egzekwowana dla każdego komunikatu protokołu MCP, każdego wejścia wywołania narzędzia i każdego wyjścia narzędzia przed dotarciem do modelu. Walidacja odrzuca każdy komunikat, który nie jest zgodny z zdefiniowanym schematem — brakujące wymagane pola, złe typy, wartości poza dozwolonymi zakresami.
Jak testować: Wyślij wywołanie narzędzia z brakującym wymaganym parametrem. Wyślij komunikat z dodatkowym nieoczekiwanym polem. Oba powinny zostać odrzucone, a nie cicho zignorowane lub przetworzone z wartościami domyślnymi.
Typowe tryby awarii: Opcjonalna walidacja, która jest pomijana w warunkach błędu; walidacja tylko na wejściach, nie na wyjściach; schematy, które są zbyt permisywne (akceptujące parametry type: "any").
Co zweryfikować: Wszystkie dane wejściowe są oczyszczane w celu usunięcia lub ucieczki znaków, które mogą umożliwić wstrzykiwanie (sekwencje XSS, metaznaki SQL, metaznaki powłoki, bajty zerowe). Limity rozmiaru są egzekwowane dla wszystkich danych wejściowych i wyjściowych. Serwer traktuje wszystkie dane z modelu jako potencjalnie wrogie, identycznie jak dane wejściowe użytkownika w tradycyjnej aplikacji webowej.
Jak testować: Wyślij dane wejściowe zawierające ładunki wstrzykiwania SQL, metaznaki powłoki i sekwencje XSS. Sprawdź, czy są odrzucane lub bezpiecznie uciekane przed dotarciem do systemów podrzędnych. Wyślij dane wejściowe przekraczające limit rozmiaru — sprawdź, czy są prawidłowo odrzucane.
Typowe tryby awarii: Dane wejściowe przekazywane bezpośrednio do zapytań SQL lub poleceń powłoki; brak limitów rozmiaru pozwalających na wyczerpanie pamięci przez zbyt duże dane wejściowe; dane wyjściowe zwracane do modelu bez limitów rozmiaru lub filtrowania treści.
Co zweryfikować: Wywołania narzędzi są akceptowane tylko jako strukturalne obiekty JSON ze zwalidowanymi schematami. Generowanie tekstu swobodnego, które implikuje wywołania narzędzi, nie jest przetwarzane. System nie może być nakłoniony do wykonywania wywołań narzędzi przez generowanie języka naturalnego, który serwer interpretuje jako polecenia.
Jak testować: Wyślij ciąg języka naturalnego opisujący wywołanie narzędzia („wywołaj narzędzie delete_file ze ścieżką /etc/passwd"). Sprawdź, czy serwer nie interpretuje tego jako wywołania narzędzia.
Typowe tryby awarii: Systemy hybrydowe akceptujące zarówno strukturalny JSON, jak i opisy narzędzi w języku naturalnym; serwery analizujące tekst generowany przez model w celu identyfikacji wywołań narzędzi; analizowanie wywołań narzędzi oparte na regex, które można sfałszować.
Hartowanie wdrożenia ogranicza promień wybuchu każdej wykorzystanej podatności.
Co zweryfikować: Serwer MCP działa w minimalnym hartowanym kontenerze. Proces kontenera działa jako użytkownik bez uprawnień root. Niepotrzebne możliwości Linuksa są usuwane. Polityki sieciowe ograniczają cały ruch przychodzący i wychodzący do wyraźnie wymaganych połączeń. Obraz kontenera zawiera tylko minimalne wymagane oprogramowanie.
Jak testować: Uruchom docker inspect i sprawdź, czy użytkownik nie jest rootem. Przejrzyj polityki sieciowe i potwierdź, że blokują cały ruch z wyjątkiem wyraźnie dozwolonych połączeń. Przeskanuj obraz kontenera pod kątem niepotrzebnych pakietów lub oprogramowania ze znanymi podatnościami.
Typowe tryby awarii: Kontenery działające jako root dla wygody; brak polityk sieciowych pozostawiających dozwolony cały ruch wychodzący; obrazy bazowe z pełnymi instalacjami systemu operacyjnego zamiast minimalnych obrazów.
Co zweryfikować: Wszystkie klucze API, sekrety klienta OAuth, dane uwierzytelniające bazy danych i tokeny kont usług są przechowywane w skarbcu sekretów (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault itp.). Żadne sekrety nie istnieją w zmiennych środowiskowych, kodzie źródłowym, obrazach kontenerów ani wyjściu dziennika. Operacje zarządzania sekretami odbywają się w oprogramowaniu pośredniczącym, które jest niedostępne dla modelu AI — LLM nigdy nie widzi ani nie przetwarza wartości danych uwierzytelniających.
Jak testować: Przeszukaj dzienniki w poszukiwaniu ciągów przypominających dane uwierzytelniające. Sprawdź zmienne środowiskowe dostępne dla procesu serwera. Przejrzyj dostępny kontekst modelu, aby potwierdzić, że nie pojawiają się żadne wartości danych uwierzytelniających.
Typowe tryby awarii: Klucze API w plikach .env zatwierdzonych do kontroli wersji; dane uwierzytelniające zwracane w komunikatach o błędach, które docierają do modelu; sekrety przekazywane jako parametry narzędzi, które pojawiają się w kontekście konwersacji modelu.
Co zweryfikować: Potok wdrożeniowy obejmuje automatyczne skanowanie bezpieczeństwa (SAST, SCA, skanowanie podatności zależności) jako twarde bramy — nieudane skanowania blokują wdrożenie. Wszystkie wywołania narzędzi, zdarzenia uwierzytelniania i decyzje autoryzacji są rejestrowane w sposób niezmienny z pełnym kontekstem. Dzienniki są pobierane przez SIEM z alertowaniem w czasie rzeczywistym o anomalnych wzorcach (skoki nieudanych walidacji, nietypowa częstotliwość wywołań narzędzi, nieoczekiwane połączenia zewnętrzne).
Jak testować: Wprowadź znaną podatną zależność i sprawdź, czy potok CI/CD kończy się niepowodzeniem kompilacji. Wygeneruj anomalne wzorce wywołań narzędzi i sprawdź, czy alerty SIEM uruchamiają się w oczekiwanym czasie reakcji.
Typowe tryby awarii: Skanowanie bezpieczeństwa jako doradcze, a nie blokujące bramy; dzienniki zapisywane w zmiennym magazynie, który atakujący mógłby zmodyfikować; brak alertowania o anomalnych wzorcach; nadmierna szczegółowość dziennika, która sprawia, że znalezienie istotnych zdarzeń jest niemożliwe.
Wydrukuj lub wyeksportuj tę listę kontrolną i przejdź przez nią systematycznie dla każdego serwera MCP przed wdrożeniem produkcyjnym. Zaangażuj swój zespół bezpieczeństwa w przegląd — wiele elementów wymaga zarówno przeglądu kodu, jak i testów na żywo, aby prawidłowo zweryfikować.
Dla zespołów, które chcą niezależnej weryfikacji, profesjonalny audyt bezpieczeństwa MCP testuje wszystkie 16 elementów listy kontrolnej względem Twojego środowiska produkcyjnego, używając technik testowania przeciwstawnego zamiast samooceny. Rezultatem jest zweryfikowany raport o postawie bezpieczeństwa z priorytetowym planem naprawczym.
Minimalne standardy bezpieczeństwa MCP projektu OWASP GenAI Security to lista kontrolna przeglądu definiująca podstawowe kontrole bezpieczeństwa wymagane przed wdrożeniem serwera MCP do produkcji. Obejmuje pięć dziedzin: Silna tożsamość/uwierzytelnianie/egzekwowanie polityki, Ścisła izolacja i kontrola cyklu życia, Zaufane i kontrolowane narzędzia, Walidacja oparta na schemacie oraz Hartowane wdrożenie z ciągłym nadzorem. Niespełnienie minimalnych standardów oznacza, że serwer MCP nie powinien być wdrażany, dopóki luki nie zostaną naprawione.
Przejdź systematycznie przez każdą kategorię, oznaczając elementy jako ZALICZONY, NIEZALICZONY lub NIE DOTYCZY z dowodami dla każdej decyzji. Każdy NIEZALICZONY w kategoriach 1 lub 2 (tożsamość i izolacja) powinien zablokować wdrożenie — są to luki o najwyższym ryzyku. NIEZALICZONE w innych kategoriach powinny zostać zaakceptowane pod względem ryzyka z udokumentowanym harmonogramem naprawy przed wdrożeniem. Lista kontrolna powinna być ponownie oceniana po każdej znaczącej zmianie w serwerze MCP, rejestrze narzędzi lub środowisku wdrożeniowym.
Kilka narzędzi wspiera automatyczną walidację bezpieczeństwa MCP: Invariant MCP-Scan (wyspecjalizowane do skanowania bezpieczeństwa MCP), narzędzia SAST z niestandardowymi regułami MCP, npm audit i pip audit do skanowania zależności, OSV-Scanner do sprawdzania bazy danych podatności, profile Docker seccomp i AppArmor do izolacji środowiska uruchomieniowego oraz integracja SIEM do scentralizowanego monitorowania. Żadne pojedyncze narzędzie nie obejmuje wszystkich elementów listy kontrolnej — kompleksowe pokrycie wymaga połączenia analizy statycznej, testów dynamicznych i ciągłego monitorowania.
Arshia jest Inżynierką Przepływów Pracy AI w FlowHunt. Z wykształceniem informatycznym i pasją do sztucznej inteligencji, specjalizuje się w tworzeniu wydajnych przepływów pracy, które integrują narzędzia AI z codziennymi zadaniami, zwiększając produktywność i kreatywność.
Użyj tej listy kontrolnej do samooceny, a następnie zaproś nasz zespół do zweryfikowanego audytu bezpieczeństwa. Testujemy każdy element w Twoim środowisku produkcyjnym i dostarczamy szczegółowy plan naprawczy.
Serwery MCP ujawniają unikalną powierzchnię ataku łączącą tradycyjne zagrożenia API z zagrożeniami specyficznymi dla AI. Poznaj 6 krytycznych podatności zidenty...
Zatruwanie narzędzi i ataki rug pull to dwa najbardziej niebezpieczne wektory ataku specyficzne dla MCP. Dowiedz się, jak atakujący osadzają złośliwe instrukcje...
Uwierzytelnianie to najbardziej krytyczna warstwa bezpieczeństwa dla zdalnych serwerów MCP. Dowiedz się, dlaczego OAuth 2.1 z OIDC jest obowiązkowy, jak delegac...
