# Bezpečně připojte AI agenty k serveru MCP společnosti Webship
Připojení MCP k webovému serveru není chatovací widget. Je to operační rozhraní, které může kontrolovat stav produkce, měnit směrování a bezpečnostní politiku, znovu načítat certifikáty, aktivovat statické verze, koordinovat změny flotily a instalovat podepsanou aktualizaci Webship.
Zacházejte s tím podle toho: jako s privilegovaným administrativním API. Nejbezpečnější nastavení Webship drží MCP posluchač mimo veřejnou datovou rovinu, svazuje ho s loopbackem, chrání ho pomocí TLS 1.3 a silného tokenu nositele a přistupuje k němu prostřednictvím autentizovaného SSH tunelu.
Tento průvodce staví toto uspořádání, vysvětluje, proč každá hranice existuje, a poskytuje vám kontrolní seznam pro jeho provozování, aniž byste pohodlí proměnili ve vystavení se riziku.
Začněte s hranicí důvěry
Veřejný provoz Webship a provoz MCP používají samostatné posluchače. Řídicí rovina MCP je ve výchozím nastavení vypnutá a nikdy nesdílí běžný HTTP, HTTP/2, HTTP/3 ani WebTransport posluchač. Po povolení poskytuje MCP přes vyhrazený TLS 1.3 HTTP/1.1 konec.
Bezpečné nasazení má čtyři nezávislé kontroly:
- Dostupnost sítě: posluchač MCP se váže na
127.0.0.1, nikoli na veřejnou nebo soukromou LAN adresu. - Identita přenosu: klient ověřuje certifikát vydaný CA, které důvěřuje.
- Autentizace aplikace: každá žádost nese jeden silný bearer token.
- Správní přístup: operátoři se dostávají k posluchači loopback přes autentizovaný SSH účet a tunel.
Žádná z těchto kontrol nenahrazuje jinou. TLS bez soukromé síťové cesty stále odhaluje autentizační povrch. Tunel bez ověření certifikátu činí identitu koncového bodu nejasnou. Přenosný token uvnitř souboru čitelného světově není tajemstvím.
Připravte certifikát a token
Vydávejte speciální certifikát MCP z vaší interní CA. Pro níže uvedený tunel zahrňte do alternativních názvů subjektu certifikátu localhost a 127.0.0.1, poté nainstalujte vydávající CA do úložiště důvěryhodných certifikátů klientského počítače MCP. Neřešte chybu důvěry pomocí nebezpečné možnosti TLS.
Vytvořte unikátní token s alespoň 32 tisknutelnými ASCII bajty a bez mezer. 32-bajtová náhodná hodnota zakódovaná jako hexadecimální vám dá 64 bezpečných znaků:
umask 077
openssl rand -hex 32Webship aktuálně čte token MCP přímo z chráněné konfigurace TOML; token_file není podporováno. Uložte výsledek do konfiguračního souboru, který je čitelný pouze pro servisní účet Webship a jeho administrativní skupinu. Nepokládejte token do jednotky systemd, historie shellu, tiketu, zprávy v chatu ani do výzvy zasílané modelu AI.
Na typickém hostiteli Debian:
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.pemPřizpůsobte uživatele služby a skupinu vaší instalaci. Soukromý klíč a konfigurace musí být čitelné pro Webship, ale nesmí být přístupné pro nesouvisející účty.
Povolit izolovaného posluchače
Přidejte tuto sekci do aktivní konfigurace 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"Prázdný seznam allowed_ips neotevírá koncový bod. Klienti na smyčce jsou ve výchozím nastavení povoleni. expose_remote = false činí zamýšlenou hranici explicitní: pokud někdo později změní listen na adresu mimo smyčku, Webship odmítne konfiguraci místo toho, aby tichounce publikoval řídicí rovinu.
Webship také odmítá povoleného MCP posluchače bez TLS, bez tokenu, s krátkým nebo obsahujícím mezery tokenem, nebo s prázdnými cestami k certifikátu. Veřejné zástupné tokeny jsou odmítnuty před vzdáleným zpřístupněním.
Ověřit před restartem
MCP posluchač, identita TLS a změny tokenu překompilují řídicí rovinu, takže vyžadují restart procesu. Nejprve ověřte kompletní konfiguraci:
/usr/local/bin/webship --check-config --config /etc/webship/production.toml
sudo systemctl restart webship
sudo systemctl status webship --no-pagerPotvrďte, že naslouchající existuje pouze na loopback:
ss -ltn | grep '127.0.0.1:9443'Nepřidávejte port 9443 do veřejných pravidel firewallu hostitele. Další krok k němu přistupuje přes SSH.
Vytvořit soukromý tunel
Z pracovní stanice administrátora přesměrujte lokální port na loopback posluchač Webship:
ssh -N \
-L 127.0.0.1:19443:127.0.0.1:9443 \
webship-admin@edge.example.comKlient MCP se nyní připojuje k https://localhost:19443/mcp. TCP dosáhne SSH serveru, SSH přenese připojení na hostitele a hostitel otevře konečné připojení k Webship na loopbacku. Ukončení SSH relace okamžitě odstraní tuto cestu.
Používejte autentizaci SSH založenou na klíči, omezte, kteří administrátoři mohou otevřít tunel, a aplikujte vaše běžné kontroly přístupu k hostiteli. Pokud je vyžadován jump host, nechte posluchač MCP na smyčkovém rozhraní (__loopback__) hostitele Webship a prodlužte SSH cestu místo rozšiřování posluchače.
Konfigurujte klienta MCP
Formáty konfigurace klienta se liší, ale typický záznam HTTP MCP vypadá takto:
{
"mcpServers": {
"webship-production": {
"url": "https://localhost:19443/mcp",
"headers": {
"Authorization": "Bearer <your-token>"
}
}
}
}Použijte chráněný tajný mechanismus klienta, pokud ho má. V opačném případě omezte konfiguraci klienta na aktuální účet operačního systému. HTTP klient—nikoli model—by měl připojit hlavičku autorizace. Nikdy nevkládejte živý token do konverzace.
Nechte ověřování certifikátu povoleno. Pokud klient certifikát odmítne, opravte alternativní názvy subjektu certifikátu nebo nainstalujte správnou interní CA. Nepřidávejte trvalé obejití.
Nastavte první relaci pouze pro čtení
Po připojení tunelu a klienta začněte s objevováním a kontrolou:
- Požádejte o
tools/list; jeho odpověď je autoritativní schéma argumentů pro běžící verzi. - Zavolejte
webship.get_configa zaznamenejte aktuální verzi konfigurace. - Zkontrolujte
webship.reverse_proxy.get_status,webship.security.get_status,webship.ddos.get_statusawebship.tls.get_status, podle potřeby. - Použijte
webship.policy.explainnebowebship.security.simulatepřed změnou politiky. - Potvrďte, že navrácená konfigurace cenzuruje bearer tokeny.
Teprve poté otestujte mutaci v nepředprodukčním prostředí. Konfigurační mutace Webship vyžadují aktuální ID verze. Zastaralý zápis je odmítnut místo přepsání novější změny. Kandidátská politika může být ověřena pomocí stínové verifikace a scénářů v testovací laboratoři před aktivací.
Webship také odmítá vybraná živá snížení bezpečnosti. Požadavek MCP nemůže vypnout aktivní WAF, DDoS vrstvu, API Shield, bot challenge, edge-auth politiku ani vrstvu hlaviček odpovědi. Změny posluchače vázaného na proces, protokolu, pracovníka, runtime a MCP autentizace vyžadují úmyslné restartování.
Ti strážci snižují chyby; nezajišťují, že každá autorizovaná akce je neškodná. Token poskytuje silné ovládací rozhraní, včetně operací aktualizace a vydání. Přezkoumávejte navrhované volání nástroje přesně tak, jako byste přezkoumávali příkaz správce v shellu.
Pokud je nevyhnutelné vzdálené vázání
Doporučeným řešením je Loopback plus SSH. Pokud vaše prostředí vyžaduje posluchač pro privátní síť, uveďte tuto výjimku explicitně:
[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"Ponechte blok TLS z předchozího příkladu, používejte certifikát odpovídající soukromému DNS jménu a uplatňujte stejný rozsah zdrojů na hostiteli i síťových firewallech. Nikdy nepoužívejte 0.0.0.0/0 nebo ::/0 jako pohodlný seznam povolených. Pamatujte, že seznam povolených aplikací vidí zdrojovou adresu, která skutečně dorazí k Webship; ověřte chování, když před ním stojí load balancer, NAT gateway nebo service mesh.
Vzdálené vystavení zvyšuje hodnotu centralizovaných přístupových logů, krátkých provozních oken a rychlé rotace. Není vyžadováno jen proto, že klient MCP běží na jiném stroji; to je přesně to, co řeší SSH tunel.
Ovládejte řídicí rovinu cíleně
Použijte tento kontrolní seznam pro výrobu:
- Nechte MCP vypnutý tam, kde jej žádný agent ani operátor nepotřebuje.
- Připojit se k loopbacku a ve výchozím nastavení použít SSH tunel.
- Použijte dedikovanou TLS identitu a mějte povolené ověřování certifikátu.
- Vygenerujte jedinečný nosný token pro každé prostředí Webship.
- Chraňte TOML, konfiguraci klienta, klíč TLS a SSH klíče pomocí oprávnění souborového systému.
- Oddělte přihlašovací údaje pro vývoj, testování a produkci.
- Spusťte relace s nástroji pro simulaci stavu a politiky před mutacemi.
- Uchovávejte a kontrolujte bezpečnostní auditní události Webship.
- Otočte token a restartujte Webship po podezření na expozici.
- Zavřete tunely, když administrativní relace skončí.
Pro reakci na incident uzavřete aktivní tunely, omezte účet SSH, vyměňte token MCP v chráněném TOML, restartujte Webship a zkontrolujte nedávné záznamy bezpečnostního auditu a verze konfigurace. Pokud by mohla být soukromá klíč TLS odhalena, vydajte nový certifikát a klíč jako součást stejného restartu. Starý token následně otestujte a potvrďte, že je odmítnut.
Řídicí rovina by měla zůstat řídicí rovinou
MCP je užitečný, protože agent může kontrolovat skutečný stav a aplikovat ověřené změny, aniž by tyto operace procházely veřejnou cestou požadavků. Tato výhoda zmizí, pokud se řadič posluchače stane dalším internetovým koncovým bodem.
Udržujte hranici jednoduchou: samostatný posluchač, zpětná dosažitelnost, ověřené TLS, jedna chráněná přihlašovací údaje nosiče, autentizovaný tunel, kontrolované změny podle verze a lidský kontrolní proces pro silné operace. Webship poskytuje protokol a bezpečnostní opatření; operátor rozhoduje, kdo k nim může přistupovat.
Tento průvodce je založen na dokumentaci operátora Webship 1.3.1, zaslaných příkladech konfigurace, MCP validačním a transportním kódu, strážcích konfiguračního běhu a katalogu nástrojů. Před jeho použitím pro jinou verzi si projděte aktuální Webship dokumentaci a odpověď běžícího serveru tools/list.