Conectează în siguranță agenții AI la serverul MCP al Webship

# Conectează în siguranță agenții AI la Webship’sMCP Server

UnMCP conexiunea la un server web nu este un widget de chat. Este o interfață de operațiuni care poate inspecta starea de producție, schimba politica de rutare și securitate, reîncărca certificatele, activa versiuni statice, coordona modificările flotei și instala un Webship actualizare.

Tratează-l în consecință: ca un API administrativ privilegiat. Cel mai sigurWebship configurarea păstreazăMCP ascultător de pe planul de date public, îl leagă de loopback, îl protejează cu TLS 1.3 și un token de portator puternic, și îl accesează printr-un tunel SSH autentificat.

Acest ghid construiește acea configurație, explică de ce există fiecare limită și îți oferă o listă de verificare pentru a o utiliza fără a transforma confortul în expunere.

Începeți cu limita de încredere

Webshiptraficul său public șiMCP traficul folosește ascultători separați. The MCP planul de control este dezactivat implicit și niciodată nu partajează HTTP-ul normal, HTTP/2, HTTP/3, sau WebTransport ascultător. Când este activat, serveșteMCP peste un dedicatTLS 1.3 HTTP/1.1 punct final.

O implementare sigură are patru controale independente:

1. Accesibilitatea rețelei: theMCP ascultătorul se leagă de127.0.0.1, nu o adresă publică sau privată-LAN.
2. Identitatea transportului: clientul verifică un certificat emis de o autoritate de certificare (CA) în care are încredere.
3. Autentificarea aplicației: fiecare cerere poartă un token bearer puternic.
4. Acces administrativ: operatorii ajung la ascultătorul loopback printr-un cont SSH autentificat și un tunel.

Nici unul dintre aceste controale nu înlocuiește pe altul. TLS fără un traseu de rețea privat expune în continuare o suprafață de autentificare. Un tunel fără verificarea certificatului face identitatea punctului final ambiguă. Un token purtător într-un fișier accesibil lumii nu este un secret.

Pregătiți certificatul și tokenul

Emite un dedicatMCP certificat de la CA internă. Pentru tunelul arătat mai jos, includelocalhost și 127.0.0.1 în numele alternative ale subiectului certificatului, apoi instalați CA-ul emitent înMCP magazinul de încredere al mașinii clientului. Nu rezolva o eroare de încredere cu o opțiune TLS nesigură.

Creează un token unic cu cel puțin 32 de octeți ASCII imprimabili și fără spații. O valoare aleatorie de 32 de octeți codificată în hexazecimal îți oferă 64 de caractere sigure:

umask 077
openssl rand -hex 32

Webship în prezent citește MCP token direct de la protejatTOML configurație; token_file nu este acceptat. Stocați rezultatul într-un fișier de configurare care poate fi citit doar de Webship cont de serviciu și grupul său administrativ. Nu plasați tokenul într-o unitate systemd, în istoricul shell-ului, în bilet, mesaj de chat sau prompt trimis unui model AI.

Pe un gazdă Debian tipică:

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

Adaptați utilizatorul și grupul serviciului la instalarea dvs. Cheia privată și configurația trebuie să fie accesibile pentru citire de cătreWebship, dar nu de conturi nelegate.

Activează ascultătorul izolat

Adaugă această secțiune la activWebship configurație:

[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"

Un golallowed_ips lista nu deschide punctul final. Clienții Loopback rămân permise în mod implicit.expose_remote = false face ca limita intenționată să fie explicită: dacă cineva o schimbă mai târziulisten către o adresă non-loopback, Webship respinge configurația în loc să publice silențios planul de control.

Webship respinge de asemenea un activatMCP ascultător fără TLS, fără un token, cu un token scurt sau care conține spații, sau cu căi de certificat goale. Tokenurile publice de substituire sunt respinse înainte de expunerea la distanță.

Validează înainte de repornire

MCP Modificările legate de listener, identitate TLS și token reconstruiască planul de control, așa că necesită o repornire a procesului. Verificați mai întâi întreaga configurație:

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

Confirmați că ascultătorul există doar pe bucla de revenire:

ss -ltn | grep '127.0.0.1:9443'

Nu adăugați portul 9443 la regulile publice de firewall ale gazdei. Următorul pas îl accesează prin SSH.

Creează tunelul privat

De la stația de lucru a administratorului, redirecționați un port local cătreWebshipascultătorul loopback al lui:

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

TheMCP clientul se conectează acum la https://localhost:19443/mcp. TCP ajunge la serverul SSH, SSH transportă conexiunea către gazdă, iar gazda deschide conexiunea finală cătreWebship pe loopback. Închiderea sesiunii SSH elimină imediat acea cale.

Folositi autentificarea SSH bazată pe chei, restricționați care administratori pot deschide tunelul și aplicați controalele normale de acces la gazdă. Dacă este necesară o gazdă intermediară, păstrațiMCP ascultător peWebship interfața de buclă inversă a gazdei și extinde calea SSH în loc să lărgești ascultătorul.

Configurează MCP client

Formatele de configurare ale clientului diferă, dar un HTTP tipic MCP intrarea arată astfel:

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

Folosește mecanismul de secret protejat al clientului atunci când există unul. În caz contrar, restricționează configurația clientului la contul curent al sistemului de operare. Clientul HTTP—nu modelul—trebuie să atașeze antetul de autorizare. Nu insera niciodată tokenul live într-o conversație.

Păstrați verificarea certificatului activată. Dacă clientul respinge certificatul, reparați numele alternative ale subiectului certificatului sau instalați CA intern corect. Nu adăugați o evitare permanentă.

Fă ca prima sesiune să fie doar pentru citire

După ce tunelul și clientul sunt conectați, începeți cu descoperirea și inspectarea:

1. Întreabă pentrutools/list; răspunsul său este schema de argument autoritară pentru versiunea curentă.
2. Sunăwebship.get_config și înregistrează versiunea curentă a configurației.
3. Inspecteazăwebship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status, și webship.tls.get_status după caz.
4. Folosește webship.policy.explain sau webship.security.simulate înainte de a schimba o politică.
5. Confirmați că configurația returnată cenzurează tokenurile de tip bearer.

Abia atunci testați o mutație într-un mediu non-producție.WebshipMutările de configurație ale ’s necesită ID-ul versiunii curente. O scriere învechită este respinsă în loc să suprascrie o modificare mai nouă. Politica candidat poate fi verificată cu verificarea shadow și cu scenariile traffic-lab înainte de activare.

Webship refuză de asemenea scăderile de securitate live selectate. UnMCP cererea nu poate dezactiva un WAF activ, un strat DDoS, API Shield, provocarea botului, politica de autentificare la margine sau un strat de anteturi de răspuns. Ascultător, protocol, lucrător, runtime și MCP-modificările de autentificare necesită o repornire deliberată.

Acei paznici reduc greșelile; ei nu fac fiecare acțiune autorizată inofensivă. Jetonul acordă o suprafață de control puternică, inclusiv operațiuni de actualizare și eliberare. Revizuiți apelurile de instrumente propuse exact așa cum ați revizui comanda shell a unui administrator.

Dacă legarea la distanță este inevitabilă

Loopback plus SSH este designul recomandat. Dacă mediul dvs. necesită un receptor pentru rețea privată, faceți excepția explicită:

[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"

Păstrați blocul TLS din exemplul anterior, folosiți un certificat care corespunde numelui DNS privat și aplicați aceeași gamă de surse la firewall-urile gazdă și de rețea. Nu folosiți niciodată0.0.0.0/0 sau ::/0 ca o listă de permisiuni pentru comoditate. Ține minte că o listă de permisiuni a aplicației vede adresa sursă care ajunge efectivWebship; verifica comportamentul atunci când un load balancer, un gateway NAT sau un service mesh se află în fața acestuia.

Expunerea de la distanță crește valoarea jurnalelor de acces centralizate, a ferestrelor operaționale scurte și a rotației rapide. Nu este necesară doar pentru căMCP clientul rulează pe o altă mașină; asta este exact ceea ce rezolvă tunelul SSH.

Operați planul de control cu bună știință

Folosește această listă de verificare pentru producție:

• Păstrează MCP dezactivat acolo unde niciun agent sau operator nu are nevoie de el.
• Leagă-te la loopback și folosește implicit un tunel SSH.
• Folosește o identitate TLS dedicată și păstrează verificarea certificatului activată.
• Generează un token de purtător unic pentru fiecareWebship mediu.
• Protejează TOML, configurarea clientului, cheia TLS și cheile SSH cu permisiuni pentru sistemul de fișiere.
• Separați acreditările pentru dezvoltare, testare și producție.
• Porniți sesiunile cu instrumente de simulare a stării și politicii înainte de mutații.
• Păstrează și revizuieșteWebshipevenimentele auditului de securitate ale ’s.
• Rotiți tokenul și repornițiWebship după expunerea suspectată.
• Închide tunelurile când se încheie sesiunea administrativă.

Pentru răspuns la incidente, închideți tunelurile active, restricționați contul SSH, înlocuiți MCP token în protejatTOML, repornește Webship, și revizuiți istoricul recent al auditurilor de securitate și al versiunilor de configurare. Dacă cheia privată TLS poate fi expusă, emiteți un certificat și o cheie noi ca parte a aceleiași reporniri. Testați apoi tokenul vechi și confirmați că este respins.

Un plan de control ar trebui să rămână un plan de control

MCP este util deoarece un agent poate inspecta starea reală și aplica modificări validate fără a redirecționa acele operațiuni prin calea de cerere publică. Acest avantaj dispare dacă ascultătorul de control devine un alt punct final de internet.

Păstrați limita simplă: un ascultător separat, accesibilitate loopback, TLS verificat, un singur credential purtător protejat, un tunel autentificat, modificări verificate la nivel de versiune și un proces de revizuire umană pentru operațiuni puternice.Webship oferă protocolul și măsurile de siguranță; operatorul decide cine poate să ajungă la ele.

Acest ghid se bazează pe Webship 1.3.1 documentația operatorului, exemple de configurare livrate,MCP cod de validare și transport, garduri de configurare în timp de execuție și catalog de unelte. Revizuiește actualul Webship documentație și serverul care rulează tools/list răspuns înainte de a-l aplica la o altă versiune.