Bezpieczne połączenie agentów AI z serwerem MCP Webship

# Bezpieczne połączenie agentów AI z serwerem MCP Webship

Połączenie MCP z serwerem internetowym nie jest widgetem czatu. Jest to interfejs operacyjny, który może sprawdzać stan produkcji, zmieniać trasowanie i politykę bezpieczeństwa, wczytywać certyfikaty, aktywować wersje statyczne, koordynować zmiany floty oraz instalować podpisaną aktualizację Webship.

Traktuj to odpowiednio: jak uprzywilejowane administracyjne API. Najbezpieczniejsza konfiguracja Webship utrzymuje nasłuch MCP z dala od publicznej warstwy danych, przypisuje go do loopback, chroni za pomocą TLS 1.3 i silnego tokenu dostępu, oraz uzyskuje do niego dostęp przez uwierzytelniony tunel SSH.

Ten przewodnik opisuje, jak zbudować to ustawienie, wyjaśnia, dlaczego istnieje każda granica, i daje ci listę kontrolną do obsługi tego systemu bez zamieniania wygody w ryzyko.

Zacznij od granicy zaufania

Ruch publiczny Webship i ruch MCP korzystają z oddzielnych nasłuchiwaczy. Płaszczyzna kontrolna MCP jest domyślnie wyłączona i nigdy nie korzysta z normalnego nasłuchiwacza HTTP, HTTP/2, HTTP/3 ani WebTransport. Po włączeniu obsługuje MCP za pośrednictwem dedykowanego końcowego punktu TLS 1.3 HTTP/1.1.

Bezpieczne wdrożenie ma cztery niezależne kontrole:

1. Dostępność sieci: nasłuchiwacz MCP jest powiązany z 127.0.0.1, a nie z adresem publicznym ani adresem sieci lokalnej (LAN).
2. Tożsamość transportowa: klient weryfikuje certyfikat wydany przez zaufany przez niego urząd certyfikacji (CA).
3. Uwierzytelnianie aplikacji: każde żądanie niesie jeden silny token dostępu.
4. Dostęp administracyjny: operatorzy łączą się z nasłuchem loopback za pośrednictwem uwierzytelnionego konta SSH i tunelu.

Żaden z tych mechanizmów kontroli nie zastępuje innego. TLS bez prywatnej ścieżki sieciowej nadal odsłania powierzchnię uwierzytelniania. Tunel bez weryfikacji certyfikatu sprawia, że tożsamość punktu końcowego jest niejednoznaczna. Token dostępu w pliku dostępnym dla całego świata nie jest tajemnicą.

Przygotuj certyfikat i token

Wydaj dedykowany certyfikat MCP z wewnętrznego CA. Dla tunelu pokazanego poniżej, uwzględnij localhost i 127.0.0.1 w alternatywnych nazwach podmiotu certyfikatu, a następnie zainstaluj wydające CA w magazynie zaufania maszyny klienckiej MCP. Nie rozwiązuj błędu zaufania za pomocą opcji niebezpiecznego TLS.

Utwórz unikalny token składający się z co najmniej 32 drukowalnych bajtów ASCII i bez białych znaków. Losowa wartość 32-bajtowa zakodowana w formacie szesnastkowym daje 64 bezpieczne znaki:

umask 077
openssl rand -hex 32

Webship odczytuje obecnie token MCP bezpośrednio z chronionej konfiguracji TOML; token_file nie jest obsługiwany. Zapisz wynik w pliku konfiguracyjnym czytelnym tylko dla konta serwisowego Webship i jego grupy administracyjnej. Nie umieszczaj tokenu w jednostce systemd, historii powłoki, zgłoszeniu, wiadomości czatu ani w zapytaniu wysyłanym do modelu AI.

Na typowym hoście Debiana:

sudo chown root:webship /etc/webship/production.toml
sudo chmod 0640 /etc/webship/production.toml
sudo chown root:webship /etc/webship/mcp-cert.pem /etc/webship/mcp-key.pem
sudo chmod 0644 /etc/webship/mcp-cert.pem
sudo chmod 0640 /etc/webship/mcp-key.pem

Dostosuj użytkownika usługi i grupę do swojej instalacji. Klucz prywatny i konfiguracja muszą być czytelne dla Webship, ale nie dla niepowiązanych kont.

Włącz izolowanego słuchacza

Dodaj tę sekcję do aktywnej konfiguracji Webship:

[security.mcp]
enabled = true
listen = "127.0.0.1:9443"
token = "replace-with-your-generated-64-character-token"
allowed_ips = []
expose_remote = false

[security.mcp.tls]
cert = "/etc/webship/mcp-cert.pem"
key = "/etc/webship/mcp-key.pem"

Pusta lista allowed_ips nie otwiera punktu końcowego. Klienci loopback pozostają dozwoleni domyślnie. expose_remote = false czyni zamierzoną granicę wyraźną: jeśli ktoś później zmieni listen na adres inny niż loopback, Webship odrzuci konfigurację zamiast cicho publikować płaszczyznę kontroli.

Webship odrzuca również włączonego słuchacza MCP bez TLS, bez tokena, z krótkim tokenem lub tokenem zawierającym spacje, lub z pustymi ścieżkami do certyfikatów. Publiczne tokeny zastępcze są odrzucane przed zdalnym udostępnieniem.

Zweryfikuj przed ponownym uruchomieniem

MCP słuchacz, tożsamość TLS i zmiany tokena odbudowują płaszczyznę kontrolną, więc wymagają ponownego uruchomienia procesu. Najpierw zweryfikuj pełną konfigurację:

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
sudo systemctl restart webship
sudo systemctl status webship --no-pager

Potwierdź, że nasłuchiwacz istnieje tylko na interfejsie loopback:

ss -ltn | grep '127.0.0.1:9443'

Nie dodawaj portu 9443 do reguł zapory publicznej hosta. Następny krok uzyskuje do niego dostęp przez SSH.

Utwórz prywatny tunel

Z stacji roboczej administratora przekieruj lokalny port do nasłuchiwacza loopback Webship:

ssh -N \
  -L 127.0.0.1:19443:127.0.0.1:9443 \
  webship-admin@edge.example.com

Klient MCP teraz łączy się z https://localhost:19443/mcp. TCP dociera do serwera SSH, SSH przenosi połączenie do hosta, a host otwiera końcowe połączenie do Webship na loopback. Zamknięcie sesji SSH natychmiast usuwa tę ścieżkę.

Używaj uwierzytelniania SSH opartego na kluczach, ogranicz, którzy administratorzy mogą otwierać tunel, i stosuj normalne kontrole dostępu do hosta. Jeśli wymagany jest host pośredni, trzymaj nasłuchiwacz MCP na interfejsie loopback hosta Webship i rozszerz ścieżkę SSH zamiast poszerzać nasłuchiwacz.

Skonfiguruj klienta MCP

Formaty konfiguracji klienta różnią się, ale typowy wpis HTTP MCP wygląda tak:

{
  "mcpServers": {
    "webship-production": {
      "url": "https://localhost:19443/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

Używaj chronionego mechanizmu tajnego klienta, gdy taki posiada. W przeciwnym razie ogranicz konfigurację klienta do bieżącego konta systemu operacyjnego. Nagłówek autoryzacji powinien dołączać klient HTTP — nie model. Nigdy nie wklejaj aktywnego tokenu w rozmowie.

Utrzymuj włączoną weryfikację certyfikatu. Jeśli klient odrzuca certyfikat, napraw alternatywne nazwy podmiotu certyfikatu lub zainstaluj odpowiedni wewnętrzny urząd certyfikacji. Nie dodawaj trwałego obejścia.

Ustaw pierwszą sesję tylko do odczytu

Po połączeniu tunelu i klienta, rozpocznij od wykrywania i inspekcji:

1. Poproś o tools/list; jego odpowiedź to autorytatywny schemat argumentów dla bieżącej wersji.
2. Zadzwoń do webship.get_config i zarejestruj bieżącą wersję konfiguracji.
3. Sprawdź webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status i webship.tls.get_status, w zależności od potrzeby.
4. Użyj webship.policy.explain lub webship.security.simulate przed zmianą polityki.
5. Potwierdź, że zwrócona konfiguracja cenzuruje tokeny dostępu.

Dopiero wtedy przetestuj mutację w środowisku nieprodukcyjnym. Mutacje konfiguracji Webship wymagają bieżącego identyfikatora wersji. Przestarzały zapis jest odrzucany zamiast nadpisywać nowszą zmianę. Politykę kandydata można sprawdzić za pomocą weryfikacji w trybie podglądu i scenariuszy w laboratorium ruchu przed aktywacją.

Webship również odrzuca wybrane obniżenia poziomu bezpieczeństwa na żywo. Żądanie MCP nie może wyłączyć aktywnego WAF, warstwy DDoS, API Shield, wyzwania dla botów, polityki edge-auth ani warstwy nagłówków odpowiedzi. Zmiany powiązane z procesem, nasłuchiwaczem, protokołem, workerem, środowiskiem uruchomieniowym i MCP-uwierzytelnianiem wymagają celowego ponownego uruchomienia.

Ci strażnicy zmniejszają liczbę błędów; nie sprawiają, że każda autoryzowana akcja jest nieszkodliwa. Token zapewnia potężny interfejs kontrolny, w tym operacje aktualizacji i wydania. Przeglądaj proponowane wywołania narzędzi dokładnie tak, jak przeglądałbyś polecenie powłoki administratora.

Jeśli zdalne wiązanie jest nieuniknione

Zalecanym rozwiązaniem jest Loopback plus SSH. Jeśli Twoje środowisko wymaga nasłuchiwacza w sieci prywatnej, wyraźnie określ wyjątek:

[security.mcp]
enabled = true
listen = "10.20.0.15:9443"
expose_remote = true
allowed_ips = ["10.20.10.0/24"]
token = "replace-with-your-generated-64-character-token"

Zachowaj blok TLS z wcześniejszego przykładu, użyj certyfikatu pasującego do prywatnej nazwy DNS i wymuś ten sam zakres źródłowy w zaporach hosta i sieci. Nigdy nie używaj 0.0.0.0/0 ani ::/0 jako wygodnej białej listy. Pamiętaj, że biała lista aplikacji widzi adres źródłowy, który faktycznie dociera do Webship; zweryfikuj działanie, gdy przed nim znajduje się load balancer, brama NAT lub siatka usług.

Zdalna ekspozycja zwiększa wartość scentralizowanych dzienników dostępu, krótkich okien operacyjnych i szybkiej rotacji. Nie jest to wymagane jedynie dlatego, że klient MCP działa na innej maszynie; dokładnie to rozwiązuje tunel SSH.

Obsługuj płaszczyznę sterowania celowo

Użyj tej listy kontrolnej do produkcji:

• Utrzymuj MCP wyłączone tam, gdzie żaden agent ani operator go nie potrzebuje.
• Powiąż z interfejsem loopback i używaj domyślnie tunelu SSH.
• Używaj dedykowanej tożsamości TLS i utrzymuj włączoną weryfikację certyfikatu.
• Wygeneruj unikalny token dostępu dla każdego środowiska Webship.
• Chroń TOML, konfigurację klienta, klucz TLS i klucze SSH za pomocą uprawnień systemu plików.
• Oddzielne dane uwierzytelniające do środowisk deweloperskiego, testowego i produkcyjnego.
• Rozpocznij sesje za pomocą narzędzi do symulacji statusu i polityk przed mutacjami.
• Zachowaj i przejrzyj zdarzenia audytu bezpieczeństwa Webship.
• Obróć token i zrestartuj Webship po podejrzeniu narażenia.
• Zamykaj tunele po zakończeniu sesji administracyjnej.

W przypadku reagowania na incydenty zamknij aktywne tunel, ogranicz konto SSH, wymień token MCP w chronionym TOML, uruchom ponownie Webship i przejrzyj ostatnie zapisy audytu bezpieczeństwa oraz wersji konfiguracji. Jeśli prywatny klucz TLS mógł zostać ujawniony, wydaj nowy certyfikat i klucz w ramach tego samego ponownego uruchomienia. Następnie przetestuj stary token i potwierdź, że jest odrzucany.

Płaszczyzna sterowania powinna pozostać płaszczyzną sterowania

MCP jest przydatny, ponieważ agent może sprawdzać rzeczywisty stan i wprowadzać zweryfikowane zmiany bez kierowania tych operacji przez publiczną ścieżkę żądań. Ta zaleta znika, jeśli nasłuch kontrolny stanie się kolejnym punktem końcowym w internecie.

Utrzymuj granicę prostą: oddzielny nasłuchiwacz, osiągalność pętli zwrotnej, zweryfikowany TLS, jedno chronione poświadczenie nośnika, uwierzytelniony tunel, zmiany weryfikowane pod kątem wersji oraz proces przeglądu przez człowieka dla potężnych operacji. Webship zapewnia protokół i zabezpieczenia; operator decyduje, kto może się do nich dostać.

Ten przewodnik opiera się na dokumentacji operatora Webship w wersji 1.3.1, dostarczonych przykładach konfiguracji, kodzie walidacji i transportu MCP, zabezpieczeniach konfiguracji w czasie pracy oraz katalogu narzędzi. Przejrzyj aktualną dokumentację Webship oraz odpowiedź działającego serwera tools/list, zanim zastosujesz go do innej wersji.