Webship bloguna geri dön

Webship mühendisliği

AI Ajanlarını Webship’nin MCP Sunucusuna Güvenli Bir Şekilde Bağlayın

TLS 1.3, güçlü bir taşıyıcı belirteci, loopback bağlaması, bir SSH tüneli, yapılandırma doğrulaması ve pratik bir olay müdahale kontrol listesi ile Webship’ın izole MCP kontrol düzlemini kurun.

# Yapay Zeka Ajanlarını Webship’in MCP Sunucusuna Güvenli Bir Şekilde Bağlayın

Bir MCP bağlantısı bir web sunucusuna bir sohbet widget'ı değildir. Bu, üretim durumunu denetleyebilen, yönlendirme ve güvenlik politikasını değiştirebilen, sertifikaları yeniden yükleyebilen, statik sürümleri etkinleştirebilen, filo değişikliklerini koordine edebilen ve imzalı bir Webship güncellemesini yükleyebilen bir operasyon arayüzüdür.

Buna uygun şekilde davranın: ayrıcalıklı bir yönetim API'si olarak. En güvenli Webship kurulumu, MCP dinleyiciyi genel veri düzleminden uzak tutar, onu loopback'e bağlar, TLS 1.3 ve güçlü bir bearer token ile korur ve ona kimlik doğrulamalı bir SSH tüneli üzerinden erişir.

Bu rehber, o kurulumu oluşturur, her sınırın neden var olduğunu açıklar ve kullanım kolaylığını riske dönüştürmeden işletmek için bir kontrol listesi sunar.

Güven sınırı ile başlayın

Webship’in genel trafiği ve MCP trafiği ayrı dinleyiciler kullanır. MCP kontrol düzlemi varsayılan olarak devre dışıdır ve normal HTTP, HTTP/2, HTTP/3 veya WebTransport dinleyicilerini asla paylaşmaz. Etkinleştirildiğinde, MCP’i özel bir TLS 1.3 HTTP/1.1 uç noktasından sunar.

Güvenli bir dağıtımın dört bağımsız kontrolü vardır:

  1. Ağ erişilebilirliği: MCP dinleyicisi 127.0.0.1 adresine bağlanır, halka açık veya özel LAN adresine değil.
  2. Taşıma kimliği: istemci, güvendiği bir Sertifika Otoritesi tarafından verilen bir sertifikayı doğrular.
  3. Uygulama kimlik doğrulaması: her istekte güçlü bir bearer token bulunur.
  4. Yönetici erişimi: operatörler, kimlik doğrulamalı bir SSH hesabı ve tünel aracılığıyla loopback dinleyicisine ulaşırlar.

Bu kontrollerin hiçbiri diğerinin yerine geçmez. Özel bir ağ yolu olmayan TLS hâlâ bir kimlik doğrulama yüzeyi açığa çıkarır. Sertifika doğrulaması olmayan bir tünel, uç nokta kimliğini belirsiz hale getirir. Dünyaya açık bir dosyanın içindeki bir taşıyıcı belirteci bir sır değildir.

Sertifikayı ve jetonu hazırlayın

Dahili CA'nızdan özel bir MCP sertifikası verin. Aşağıda gösterilen tünel için sertifikanın konu alternatif adlarına localhost ve 127.0.0.1 öğelerini ekleyin, ardından veren CA'yı MCP istemci makinesinin güven deposuna kurun. Güven hatasını güvensiz-TLS seçeneği ile çözmeyin.

En az 32 yazdırılabilir ASCII baytı olan ve boşluk içermeyen benzersiz bir jeton oluşturun. Onaltılık olarak kodlanmış 32 baytlık rastgele bir değer size 64 güvenli karakter verir:

umask 077
openssl rand -hex 32

Webship şu anda MCP belirtecini korumalı TOML yapılandırmasından doğrudan okumaktadır; token_file desteklenmemektedir. Sonucu yalnızca Webship servis hesabı ve onun yönetici grubunun okuyabileceği bir yapılandırma dosyasına kaydedin. Belirteci systemd biriminde, kabuk geçmişinde, biletlerde, sohbet mesajında veya bir yapay zeka modeline gönderilen istemde bulundurmayın.

Tipik bir Debian sunucusunda:

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

Hizmet kullanıcısını ve grubunu kurulumunuza uyarlayın. Özel anahtar ve yapılandırma Webship tarafından okunabilir olmalı, ancak ilgisiz hesaplar tarafından okunamaz.

İzolasyonlu dinleyiciyi etkinleştir

Bu bölümü aktif Webship yapılandırmasına ekleyin:

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

Boş bir allowed_ips listesi uç noktayı açmaz. Döngü geri dönüş (loopback) istemcileri varsayılan olarak izinli kalır. expose_remote = false, amaçlanan sınırı açıkça belirtir: biri daha sonra listen değerini döngü geri dönüş olmayan bir adrese değiştirirse, Webship yapılandırmayı reddeder ve kontrol düzlemini sessizce yayınlamaz.

Webship, TLS olmadan, token olmadan, kısa veya boşluk içeren token ile ya da boş sertifika yollarıyla etkinleştirilmiş bir MCP dinleyicisini de reddeder. Genel yer tutucu tokenler, uzak erişime açılmadan önce reddedilir.

Yeniden başlatmadan önce doğrula

MCP dinleyici, TLS kimliği ve belirteç değişiklikleri kontrol düzlemini yeniden oluşturur, bu nedenle bir işlem yeniden başlatması gerektirir. Önce tam yapılandırmayı doğrulayın:

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

Dinleyicinin yalnızca döngü geri dönüşünde var olduğunu doğrulayın:

ss -ltn | grep '127.0.0.1:9443'

9443 numaralı portu ana bilgisayarın genel güvenlik duvarı kurallarına eklemeyin. Bir sonraki adımda ona SSH üzerinden erişilecektir.

Özel tüneli oluştur

Yönetici iş istasyonundan, yerel bir portu Webship’in döngüsel dinleyicisine yönlendirin:

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

MCP istemcisi artık https://localhost:19443/mcp ile bağlantı kuruyor. TCP SSH sunucusuna ulaşıyor, SSH bağlantıyı ana bilgisayara taşıyor ve ana bilgisayar loopback üzerinden Webship ile nihai bağlantıyı açıyor. SSH oturumu kapatıldığında bu yol hemen kaldırılıyor.

Anahtar tabanlı SSH kimlik doğrulamasını kullanın, hangi yöneticilerin tüneli açabileceğini kısıtlayın ve normal sunucu erişim kontrollerinizi uygulayın. Bir geçiş sunucusu gerekiyorsa, MCP dinleyiciyi Webship sunucusunun loopback arayüzünde tutun ve dinleyiciyi genişletmek yerine SSH yolunu uzatın.

MCP istemcisini yapılandır

İstemci yapılandırma formatları farklılık gösterir, ancak tipik bir HTTP MCP girdisi şöyle görünür:

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

Müşterinin korumalı gizli mekanizmasını kullanın, eğer varsa. Aksi takdirde, müşteri yapılandırmasını mevcut işletim sistemi hesabıyla sınırlayın. Yetkilendirme başlığını eklemesi gereken HTTP istemcisidir, model değil. Canlı tokeni asla bir konuşmaya yapıştırmayın.

Sertifika doğrulamasını etkin tutun. Eğer istemci sertifikayı reddederse, sertifikanın konu alternatif adlarını düzeltin veya doğru dahili CA'yı yükleyin. Kalıcı bir atlama eklemeyin.

İlk oturumu salt okunur yap

Tünel ve istemci bağlandıktan sonra, keşif ve inceleme ile başlayın:

  1. tools/list'i isteyin; yanıtı, çalışan sürüm için yetkili argüman şemasıdır.
  2. webship.get_config'yi arayın ve mevcut yapılandırma sürümünü kaydedin.
  3. webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status ve webship.tls.get_status gerektiği şekilde denetleyin.
  4. Bir politikayı değiştirmeden önce webship.policy.explain veya webship.security.simulate kullanın.
  5. Dönen yapılandırmanın taşıyıcı jetonları gizlediğini doğrulayın.

Yalnızca o zaman bir mutasyonu üretim dışı bir ortamda test edin. Webship'in yapılandırma mutasyonları mevcut sürüm kimliğini gerektirir. Eski bir yazım, daha yeni bir değişikliği üzerine yazmak yerine reddedilir. Aday politika, etkinleştirmeden önce gölge doğrulama ve trafik-lab senaryoları ile kontrol edilebilir.

Webship ayrıca seçilmiş canlı güvenlik düşürmelerini de reddeder. Bir MCP isteği aktif bir WAF’ı, DDoS katmanını, API Shield’i, bot doğrulamasını, kenar-doğrulama politikasını veya yanıt-üstbilgi katmanını kapatamaz. İşlem-bağlı dinleyici, protokol, çalışan, çalışma zamanı ve MCP-kimlik doğrulama değişiklikleri kasıtlı bir yeniden başlatma gerektirir.

O muhafızlar hataları azaltır; her yetkili işlemi zararsız hale getirmezler. Jeton, güncelleme ve serbest bırakma işlemleri de dahil olmak üzere güçlü bir kontrol yüzeyi sağlar. Önerilen araç çağrılarını, bir yöneticinin kabuk komutunu inceler gibi tam olarak gözden geçirin.

Uzaktan bağlama kaçınılmazsa

Loopback ve SSH önerilen tasarımdır. Ortamınız özel ağ dinleyicisi gerektiriyorsa, istisnayı açıkça belirtin:

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

Önceki örnekten TLS bloğunu koruyun, özel DNS adıyla eşleşen bir sertifika kullanın ve aynı kaynak aralığını hem sunucu hem de ağ güvenlik duvarlarında uygulayın. Hiçbir zaman 0.0.0.0/0 veya ::/0 kullanarak kolaylık sağlanan bir izin listesi oluşturmayın. Bir uygulama izin listesi, aslında Webship adresine ulaşan kaynak adresini görür; önünde bir yük dengeleyici, NAT ağ geçidi veya servis ağı olması durumunda davranışı doğrulayın.

Uzaktan maruziyet, merkezi erişim günlüklerinin, kısa operasyonel pencerelerin ve hızlı rotasyonun değerini artırır. Bu, sadece MCP istemcisi başka bir makinede çalıştığı için gerekli değildir; işte SSH tünelinin tam olarak çözdüğü şey budur.

Kontrol düzlemini kasıtlı olarak işletin

Üretim için bu kontrol listesi kullanın:

  • MCP'i, hiçbir acente veya operatörün ihtiyaç duymadığı yerlerde devre dışı bırakın.
  • Varsayılan olarak döngü adresine bağlanın ve bir SSH tüneli kullanın.
  • Özel bir TLS kimliği kullanın ve sertifika doğrulamasını etkin tutun.
  • Her Webship ortamı için benzersiz bir taşıyıcı belirteci oluşturun.
  • Dosya sistemi izinleriyle TOML, istemci yapılandırmasını, TLS anahtarını ve SSH anahtarlarını koruyun.
  • Geliştirme, test ve üretim kimlik bilgilerini ayrı tutun.
  • Mutasyonlardan önce durum ve politika simülasyon araçlarıyla oturumlara başlayın.
  • Webship güvenlik denetim olaylarını koruyun ve gözden geçirin.
  • Token'ı döndürün ve olası maruziyet sonrası Webship'yı yeniden başlatın.
  • Yönetim oturumu sona erdiğinde tünelleri kapatın.

Olay müdahalesi için, aktif tünelleri kapatın, SSH hesabını kısıtlayın, korumalı TOML'daki MCP belirtecini değiştirin, Webship'yi yeniden başlatın ve son güvenlik denetimi ve yapılandırma sürümü kayıtlarını inceleyin. TLS özel anahtarının açığa çıkmış olabileceği durumlarda, aynı yeniden başlatma kapsamında yeni bir sertifika ve anahtar çıkarın. Daha sonra eski belirteci test edin ve reddedildiğini doğrulayın.

Bir kontrol düzlemi, bir kontrol düzlemi olarak kalmalıdır

MCP faydalıdır çünkü bir ajan gerçek durumu inceleyebilir ve doğrulanmış değişiklikleri halka açık istek yolu üzerinden yönlendirmeden uygulayabilir. Bu avantaj, kontrol dinleyicisi başka bir internet uç noktası haline gelirse ortadan kalkar.

Sınırı basit tutun: ayrı bir dinleyici, loopback erişilebilirliği, doğrulanmış TLS, bir korumalı taşıyıcı kimliği, doğrulanmış bir tünel, sürüm kontrolü yapılmış değişiklikler ve güçlü işlemler için insan inceleme süreci. Webship protokolü ve güvenlik önlemlerini sağlar; operatör kimin onlara ulaşabileceğine karar verir.

Bu kılavuz, Webship 1.3.1 operatör dokümantasyonu, gönderilen yapılandırma örnekleri, MCP doğrulama ve taşıma kodu, çalışma zamanı yapılandırma korumaları ve araç kataloğu temel alınarak hazırlanmıştır. Başka bir sürüme uygulamadan önce güncel Webship dokümantasyonunu ve çalışan sunucunun tools/list yanıtını inceleyin.