Połączenie MCP to sposób na ujawnienie możliwości, a nie powód, aby ufać każdej oferowanej przez niego operacji. Przed podłączeniem analityka uwierzytelniania określ, którego najemcę może on sprawdzać, jakie dowody może pobierać i jakie akcje pozostają niedostępne. Przypisanie odczytu raportu nie powinno dziedziczyć publikowania DNS tylko dlatego, że jeden serwer oferuje oba narzędzia.
Zacznij od rzeczywistej ścieżki danych
Mapuj aplikację hosta, klienta MCP, serwer, magazyn raportów i dowolne API. Zapisz, gdzie kończą się tokeny i która organizacja obsługuje każdy komponent. The Specyfikacja autoryzacji MCP opisuje autoryzację dla transportów opartych na protokole HTTP; nie zakładaj, że jego przepływ ma zastosowanie bez zmian do lokalnych serwerów stdio. Lokalny plik wykonywalny może mieć dostęp do systemu plików lub środowiska nawet bez zdalnej wymiany OAuth.
Oddzielne pobieranie raportów od pobierania nieprzetworzonych wiadomości. Zbiorcze liczniki mogą dać odpowiedź na pytanie dotyczące trendów nadawczych bez ujawniania tematów wiadomości, odbiorców ani załączników. Wymuś izolację dzierżawy na serwerze przy użyciu uwierzytelnionego kontekstu, zamiast akceptować nazwę dzierżawy dostarczoną przez model jako uprawnienia. Zwracaj stabilne identyfikatory źródła, aby można było prześledzić podsumowanie bez ujawniania nieograniczonych adresów URL przechowywania.
Ogranicz dane uwierzytelniające i zasięg narzędzi
Użyj poświadczeń z minimalnym obsługiwanym zakresem zasobów i działań. Zachowaj tajemnice w zatwierdzonym mechanizmie uwierzytelniania, a nie w monitach, opisach narzędzi, polach raportów lub dziennikach. The Wytyczne dotyczące bezpieczeństwa MCP zabrania przekazywania tokenu: serwer nie może po prostu akceptować i przekazywać tokenu nadrzędnego przeznaczonego dla innej usługi. Zweryfikuj zamierzoną grupę odbiorców i wprowadź odpowiednią relację autoryzacji na dalszym etapie.
Inwentarizuj każde odsłonięte narzędzie, w tym ogólne funkcje HTTP, powłoki i zapisu plików. Ukrycie przycisku specyficznego dla DNS niewiele daje, jeśli ogólne narzędzie wykonawcze może wywołać tego samego dostawcę z szerokimi uprawnieniami. Usuń niepotrzebne możliwości na granicy wykonania. Adnotacje i nazwy opisowe narzędzi mogą pomóc klientom w prezentacji narzędzi, ale nie zastępują wymuszonej autoryzacji.
Ćwicz wrogą treść raportu
W przypadku poniższych zasad pisemnych załóżmy, że dzierżawca A jest uwierzytelniony i ma zatwierdzone zadanie analizy raportów. Dozwolony jest tylko raport read_report dla dzierżawcy A. Treść raportu z prośbą o publikację tajną lub DNS nie może rozszerzyć tego uprawnienia. Jest to proponowana polityka, a nie wykonany test bezpieczeństwa lub zweryfikowana konfiguracja serwera.
Traktuj tekst raportu, próbki wiadomości i instrukcje zwracane przez serwer jako niezaufany dowód. Ciąg podający się za administratora nie staje się osobą zatwierdzającą. Analityk może określić ten ciąg jako podejrzany, nie przestrzegając go. OWASP zaleca obronę warstwową, ponieważ samo sformułowanie instrukcji nie eliminuje szybkiego wstrzyknięcia.
Sprawdź pełną księgę decyzji
- Sprawa znanego właściciela: najemca A, zatwierdzone zadanie, raport odczytu dla A. Zezwól w ramach proponowanej polityki; w obliczeniach wykorzystuje się wyłącznie zatwierdzone zwrócone dowody.
- Przypadek niewłaściwej dzierżawy: uwierzytelniony A żąda dzierżawcy B. Odmów odczytu niezależnie od jakiejkolwiek etykiety dzierżawcy w raporcie.
- Sprawa dotycząca wrogiej treści: zgłoś żądania tekstowe read_secret i publikuj_dns. Odrzuć oba narzędzia; autoryzowany raport read_report dla A może być kontynuowany, a wrogi tekst będzie traktowany jedynie jako dane.
- Przypadek niejednoznacznego właściciela: w raporcie A jako potencjalnych właścicieli wymienia się aplikację A i aplikację B. Zezwalaj tylko na autoryzowane gromadzenie dowodów, oznaczaj tożsamość jako nierozstrzygniętą i eskaluj atrybucję zamiast wybierać właściciela.
- Sprawa dotycząca niezatwierdzonego zadania: nie istnieje zatwierdzone dochodzenie. Wstrzymaj pobieranie sterowane zadaniami do czasu wyjaśnienia autoryzacji, nawet jeśli dane uwierzytelniające technicznie pozwalają na odczyt.
Dla tej księgi nie wykonano żadnych wywołań narzędzi, oceny modelu, wydawania poświadczeń ani testów granicznych. Reguły te wymagają testów implementacji w odniesieniu do rzeczywistych uprawnień serwera i dalszych serwerów, zanim ktokolwiek będzie twierdził, że są egzekwowane.
Sprawdź działanie i cofnij dostęp
Rejestruj nazwę narzędzia, uwierzytelnionego najemcę, odniesienia do dowodów i wynik autoryzacji bez kopiowania tokenów. Testuj wygaśnięcie i unieważnienie dostępu, w tym aktywne sesje i uprawnienia podrzędne. Pomyślne rozłączenie u klienta nie wystarczy, jeśli długoterminowa referencja dostawcy pozostaje ważna gdzie indziej.
Zacznij od pilotażu tylko do odczytu i wyraźnej listy pytań, na które analityk powinien odpowiedzieć. Sprawdź, czy odmowy są przydatne: powinny wskazywać brakujące dowody lub zakres, a nie dyskretnie pomijać najemcę lub sfabrykować wynik. Rozszerz uprawnienia dopiero po osobnym przejrzeniu nowej akcji. To jest proponowany wzorzec kontroli, a nie zweryfikowana funkcja produktu EmailAuth .