Serwer MCP w produkcji: lista kontrolna przed dopuszczeniem
Serwer MCP zatwierdzaj do produkcji dla konkretnej wersji i listy narzędzi. Lista kontrolna: pochodzenie kodu, tokeny, uruchomienie, logi, warunki odmowy.
Dla: Zespoły bezpieczeństwa, platformowe i właściciele systemów · Stan na 02.11.2026 · Autor: Karol Krawczyk
Co zatwierdzasz, dopuszczając serwer MCP do produkcji?
Zatwierdzenie serwera MCP obejmuje konkretną wersję kodu i listę narzędzi, co pokazuje nieoficjalny pakiet postmark-mcp z npm, który działał poprawnie przez 15 wersji. Według opisu Koi Security cytowanego przez CSO 26 września 2025 dopiero wersja 1.0.16, wydana 17 września 2025 według rejestru npm, dodała jedną linię: ukrytą kopię każdego wysyłanego maila na adres atakującego. Postmark pisze o fałszywym pakiecie, który nieuczciwy autor stworzył pod jego nazwą i przez 15 wersji budował zaufanie. Przykład hipotetyczny: firma zatwierdza ten pakiet przy wersji 1.0.15 i używa npx bez przypiętej wersji, więc zgoda przechodzi na złośliwy kod bez żadnego przeglądu.
Propozycja tego tekstu, nie norma: wpis w rejestrze zatwierdzeń opisuje parę, czyli wersję kodu i odcisk listy narzędzi z ich opisami. Zmiana któregokolwiek elementu wraca do przeglądu. Przy serwerach zdalnych nie przypniesz kodu, więc kontrola opiera się tam na umowie z dostawcą i porównaniu opisów narzędzi. Listę stosuj proporcjonalnie: serwer tylko do odczytu danych publicznych przejdzie szybko, a serwer zapisujący do systemu finansowego przejdzie każdy punkt.
Pochodzenie serwera MCP i łańcuch dostaw
Wpis w oficjalnym rejestrze MCP nie wystarcza do oceny pochodzenia serwera: weryfikacja przestrzeni nazw potwierdza właściciela nazwy, a serwerów z lukami rejestr nie usuwa.
- Znany wydawca: serwer pochodzi od producenta systemu albo od zespołu, którego repozytorium przejrzano. Nazwa pakietu podobna do znanej marki nic nie dowodzi.
- Wersja przypięta do numeru lub skrótu, kopia w firmowym rejestrze pakietów, bez instalacji najnowszej wersji przy każdym starcie.
- Zależności sprawdzone skanerem SCA, włącznie z narzędziami pomocniczymi. Przykład: mcp-remote w wersjach od 0.0.5 do 0.1.15 miał lukę CVE-2025-6514 (CVSS 9.6 według JFrog), w której złośliwy serwer przez spreparowany authorization_endpoint wykonywał polecenia w systemie klienta.
- Jest osoba odpowiedzialna za aktualizacje i ustalony czas reakcji na poprawki bezpieczeństwa.
Tożsamość i tokeny serwera MCP
Tożsamość i tokeny serwera MCP zależą od transportu: dla serwerów HTTP sprawdzasz zgodność z rozdziałem specyfikacji o autoryzacji, zwłaszcza z punktami wymienionymi niżej. Dla stdio pytania są inne: skąd proces bierze poświadczenia i jak daleko one sięgają.
- Serwer odrzuca tokeny wydane dla innego odbiorcy. Specyfikacja mówi o tym MUST.
- Serwer nie przekazuje dalej tokenu klienta. Do API docelowego używa osobnego tokenu. To także MUST.
- Działania wykonywane są jako konkretny użytkownik albo nazwana tożsamość usługowa, z pełnym przypisaniem w logu systemu docelowego.
- Zakresy są wąskie: bez *, all, full-access. Podwyższanie uprawnień przebiega przez wyzwanie zakresu, nie przez pełen zestaw na starcie.
- Bez długowiecznych osobistych tokenów. Sekret trzymany jest w menedżerze sekretów, a nie w pliku konfiguracyjnym czytelnym dla każdego użytkownika maszyny.
- Tokeny dostępu krótkotrwałe, a dla klientów publicznych rotacja refresh tokenów (to wymóg wobec serwera autoryzacji).
- Uchwyty stanu są losowe i związane z użytkownikiem. Znajomość uchwytu nie daje dostępu.
Uruchomienie serwera MCP i izolacja w sieci
Lokalny serwer MCP działa z uprawnieniami użytkownika. Dokument z dobrymi praktykami wylicza sandboxing jako zalecenie dla klienta, nie gwarancję, więc na produkcji trzeba go zapewnić samemu: kontener, ograniczony system plików, brak dostępu do kluczy SSH i katalogu domowego. Backslash Security w badaniu z czerwca 2025 (ponad 7 tysięcy publicznie dostępnych serwerów, dane za Infosecurity Magazine) znalazł ich setki dostępne dla każdego w tej samej sieci lokalnej. Liczba ma ponad rok i pochodzi od dostawcy, a kontrola sprowadza się do ustawienia adresu nasłuchu.
Serwer HTTP musi walidować nagłówek Origin i odpowiadać 403 na nieprawidłowy, bo inaczej strona WWW może dotrzeć do lokalnej usługi przez DNS rebinding. Lokalnie powinien (SHOULD) słuchać na 127.0.0.1. Ruch wychodzący ogranicz do listy potrzebnych miejsc, co jednocześnie zawęża drogę wycieku po udanym ataku. Klient wdrożony na serwerze powinien też blokować adresy prywatne i 169.254.169.254 przy pobieraniu adresów OAuth, czyli SSRF przez metadane podane przez złośliwy serwer.
Jak przejrzeć narzędzia serwera MCP?
Przegląd serwera MCP to w dużej mierze czytanie tools/list. Pobierz definicje, zapisz odcisk i przejrzyj każdą pozycję z właścicielem systemu docelowego. Specyfikacja wymaga od serwera walidacji wejścia, kontroli dostępu, limitów wywołań i sanityzacji wyjścia, więc o to zapytaj wprost lub sprawdź w kodzie.
- Każde narzędzie ma uzasadnienie biznesowe. Reszta jest wyłączona na serwerze, w kliencie albo w bramie.
- Adnotacje typu read-only lub destructive traktujesz jako deklarację. Specyfikacja nakazuje uznawać je za niezaufane, chyba że pochodzą z zaufanego serwera, więc potwierdź je w kodzie lub testem.
- Działania nieodwracalne i wysyłające dane na zewnątrz wymagają zgody człowieka, a podsumowanie pokazuje pełne argumenty.
- Opisy i schematy nie zawierają poleceń do modelu ani ukrytych instrukcji.
- Parametry z x-mcp-header nie obejmują danych wrażliwych, bo nagłówki widzą pośrednicy.
- Limity i timeouty są ustawione tak, by pętla agenta nie zalała systemu docelowego.
Wersja protokołu MCP i cykl życia serwera
Serwer MCP z ubiegłorocznego repozytorium może działać, a mimo to dokładać dług. Ustal, które rewizje MCP obsługuje, i czy korzysta z funkcji z rejestru wycofań rewizji 2026-07-28: Roots, Sampling, Logging albo transportu HTTP+SSE. Pierwsze trzy można usunąć najwcześniej w rewizji wydanej 2027-07-28 lub później, więc zależny od nich serwer musi mieć plan migracji. Jeśli serwer stał się bezstanowy dopiero po aktualizacji, przejrzyj od nowa obsługę uchwytów zastępujących sesje.
Metadane w oficjalnym rejestrze mają pole status, które może przyjąć wartość deprecated lub deleted, a usunięcie zwykle oznacza naruszenie regulaminu, na przykład spam albo malware. Sprawdzaj ten status cyklicznie dla zatwierdzonych pozycji. Zaplanuj też koniec życia serwera: kto usuwa go z polityki, kto unieważnia poświadczenia i czy zależą od niego inne przepływy.
Logi, wyłączanie i warunki odmowy dla serwera MCP
Przy serwerze MCP spytaj, co da się udowodnić po incydencie. Potrzebujesz kto wywołał, które narzędzie, z jakimi argumentami, z jakim wynikiem, po stronie klienta albo bramy, oraz korelacji z logiem systemu docelowego. W logach nie może być nagłówków Authorization ani tokenów, a argumenty mogą zawierać dane osobowe, więc retencję ustal świadomie. Rewizja 2026-07-28 dokumentuje konwencje przekazywania kontekstu śledzenia OpenTelemetry i tam też kieruje logowanie, bo funkcja Logging w protokole jest wycofywana.
Sprawdź wyłączanie, zanim będzie potrzebne. Ktoś na dyżurze musi umieć zablokować serwer w polityce klienta lub bramy i unieważnić jego poświadczenia, a próba takiego wyłączenia powinna odbyć się przed startem.
Propozycja tego tekstu oparta na wymaganiach specyfikacji: odmawiaj od razu, gdy wystąpi choć jeden z poniższych warunków:
- serwer HTTP bez autoryzacji sięga do danych nieprzeznaczonych do publikacji
- token przechodzi przez serwer bez walidacji odbiorcy
- brak właściciela albo nieznane pochodzenie kodu
- jedno współdzielone konto z pełnym dostępem, bez śladu, kto działał
- narzędzie ogólnego przeznaczenia (dowolny SQL, powłoka) podłączone do danych produkcyjnych bez zatwierdzania wywołań
Co zrobić w firmie
- Przypisz serwerowi klasę ryzyka i właściciela
- Przypnij wersję, skopiuj pakiet do firmowego rejestru i uruchom skan zależności
- Sprawdź autoryzację według specyfikacji albo pochodzenie poświadczeń przy stdio
- Pobierz tools/list, zapisz odcisk definicji i wyłącz niepotrzebne narzędzia
- Wykonaj próbę wyłączenia i unieważnienia poświadczeń oraz sprawdź kompletność logów
- Wpisz zatwierdzoną parę: wersja i odcisk narzędzi, każda zmiana wraca do przeglądu
Powiązane materiały
Źródła
- Model Context Protocol: Authorization (2026-07-28)
- Model Context Protocol: Authorization Security Considerations
- Model Context Protocol: Security Best Practices
- Model Context Protocol: Understanding Authorization in MCP
- Model Context Protocol: Streamable HTTP
- Model Context Protocol: Tools
- Model Context Protocol: Key Changes 2026-07-28
- Model Context Protocol: The MCP Registry
- Model Context Protocol: Registry Moderation Policy
- CSO Online: Trust in MCP takes first in-the-wild hit via squatted Postmark connector
- JFrog: mcp-remote command injection (CVE-2025-6514)
- Infosecurity Magazine: Hundreds of MCP Servers at Risk of RCE and Data Leaks
- Postmark: Security Alert, Malicious 'postmark-mcp' npm Package Impersonating Postmark (25.09.2025)
- Rejestr npm: metadane pakietu postmark-mcp
- Backslash Security: Hundreds of MCP Servers Vulnerable to Abuse (25.06.2025)
- Claude Code Docs: Control MCP server access for your organization
- Model Context Protocol: Deprecated Features
- Model Context Protocol: Registry Aggregators
Chcesz przełożyć to na swój zespół?
Szkolimy zespoły z pracy z Copilotem, Claude Code i Codexem na ich własnych zadaniach.