Salt-okuma, ağ erişimi, yazma, shell ve yönetici işlemlerini aynı politikada tutmayın.
Bir MCP sunucusunun en büyük riski portunun açık olması değil, modele hangi yetkiyi hangi koşulla verdiğinin belirsiz olmasıdır. Dosya sistemi, shell, Git, e-posta veya veritabanı tool’ları aynı güvenlik sınıfında değildir.
Shell veya dosya yazma yetkisi olan bir MCP tool’unu düşük yetkili servis hesabı, allow-list ve izole çalışma dizini olmadan üretime açmayın.
MCP sunucusunu internete açmadan önce her tool için veri sınıfı, izin seviyesi, kullanıcı onayı, ağ erişimi ve audit log gereksinimini tanımlayın. Tool listesi bir API yüzeyidir; “yerelde çalışıyor” olması güvenli olduğu anlamına gelmez.
MCP sunucusunu internete açmadan önce her tool için veri sınıfı, izin seviyesi, kullanıcı onayı, ağ erişimi ve audit log gereksinimini tanımlayın. Tool listesi bir API yüzeyidir; “yerelde çalışıyor” olması güvenli olduğu anlamına gelmez.
MCP sunucularında shadow server, aşırı yetkili tool, prompt injection, secret sızıntısı, SSRF ve uzaktan komut risklerini tehdit modeliyle ele alın; üretim sertleştirme kontrol listesi uygulayın.
Salt-okuma, ağ erişimi, yazma, shell ve yönetici işlemlerini aynı politikada tutmayın.
Geliştirme sunucusunu tüm arayüzlere bind etmek, firewall olmasa beklenmedik dış erişim yaratabilir.
Shell tool’da kara liste yerine izinli komut ve argüman şablonları daha savunulabilir bir modeldir.
Her tool çağrısını kullanıcı, istemci, tool adı ve korelasyon kimliğiyle ilişkilendirin.
Güvenlik ayarı yapmadan önce hangi MCP sunucusunun hangi veriye ve sisteme eriştiğini bilmeniz gerekir. Shadow MCP problemi çoğu zaman görünmeyen envanter problemidir.
| Tool türü | Örnek | Varsayılan risk |
|---|---|---|
| Salt-okunur bilgi | Doküman arama | Düşük-Orta |
| Harici ağ | URL fetch / webhook | Orta-Yüksek: SSRF |
| Dosya yazma | Repo düzenleme | Yüksek |
| Shell / exec | Komut çalıştırma | Çok yüksek |
Bir tool kullanıcıdan URL alıp fetch ediyorsa yalnız internet adresleri değil metadata endpoint’leri ve iç ağ servisleri de hedef olabilir.
Modelin secret görmesi çoğu zaman gereksizdir. Tool, gerekli credential’ı sunucu tarafında kullanıp yalnız sonucu döndürmelidir.
“Komut çalıştır” aracı en güçlü ve en yanlış kullanılabilir MCP yüzeylerinden biridir. Serbest metni doğrudan shell’e geçirmekten kaçının.
| Kontrol | Zayıf yaklaşım | Daha güvenli yaklaşım |
|---|---|---|
| Komut seçimi | Serbest shell string | Önceden tanımlı action ID |
| Dosya yolu | Her yol kabul | Jail/chroot çalışma kökü |
| Yetki | root/admin | Ayrı düşük yetkili kullanıcı |
| Onay | Her çağrı otomatik | Yıkıcı eylemlerde kullanıcı onayı |
MCP istemcisi “bağlandı” demeden önce hangi portun, sürecin ve reverse proxy route’unun açık olduğunu işletim sistemi seviyesinde görün.
ss -lntupsystemctl --faileddocker ps --format "table {{.Names}} {{.Ports}} {{.Status}}"journalctl -u mcp-server --since "30 min ago" --no-pagerMCP olayında ilk refleks modeli değiştirmek değil, yetkiyi kesmek ve kanıtı korumaktır.
Reverse proxy, private network, firewall, düşük yetkili servis hesapları ve merkezi log yapısı sunucunun kendisi kadar önemlidir. Eka Sunucu üzerinde izole bir MCP altyapısı planlayabilirsiniz.
Rehber hazırlanırken esas alınan birincil dokümantasyon ve teknik kaynaklar.
İlgili altyapı ve uygulama rehberleriyle devam edin.
MCP Sunucu Güvenliği
Kurumsal envanter ve güvenlik politikası dışında çalışan, ekiplerin farkında olmadığı veya onaylamadığı MCP sunucusu/entegrasyonu için kullanılan pratik bir ifadedir.
Riski azaltır ama tek başına yeterli değildir. Aynı hosttaki süreçler, reverse proxy ve local privilege escalation senaryoları hâlâ değerlendirilmelidir.
Tek bir filtreyle garanti edilemez. Etkiyi azaltmanın ana yolu model talimatından bağımsız, sunucu tarafı yetki ve parametre sınırları koymaktır.
Hayır, ancak üretimde yüksek riskli kabul edilmelidir. Serbest shell yerine sınırlı action’lar ve düşük yetkili kullanıcı tercih edilmelidir.