Bu Help Net Security röportajında, MCP Manager CEO’su Michael Yaroshefsky, Model Bağlam Protokolü’nün (MCP) güven modelinin, birçok ekibin gözden kaçırdığı güvenlik açıklarını nasıl yarattığını ve MCP’nin neden standart bir API gibi ele alınmaması gerektiğini tartışıyor. MCP’nin çalışma zamanı davranışı, yönetimi ve kimlik gereksinimleri hakkındaki yanlış anlamaların nasıl teşhir yaratabileceğini açıklıyor. MCP kullanımının kuruluşlar arasında yaygınlaşmasıyla birlikte, iyi tanımlanmış kontroller ve protokolün doğru anlaşılması gerekli hale geliyor.
MCP’nin güven modelinin şu anda en çok hangi yönleri yanlış anlaşılıyor ve uygulayıcıların yanlış varsayımlarda bulunduğu gerçek bir örneği paylaşabilir misiniz?
Birçok kişi, MCP sunucuları ve istemcileri arasındaki iletişimin esasen API tabanlı işlemlerle aynı olduğu konusunda hatalı (ve tehlikeli) bir varsayıma sahiptir. Ancak MCP ve API’ler, özellikle güvenlik duruşunuz söz konusu olduğunda inanılmaz derecede farklıdır. Aksini düşünmek tehlikelidir.
API’ler genellikle hassas ortamlarda rastgele, güvenilmeyen kodların çalıştırılmasına neden olmaz. Ancak MCP bunu yapar, bu da tamamen farklı bir güvenlik modeline ihtiyacınız olduğu anlamına gelir. Yüksek Lisans’lar metni talimat olarak ele alır, onlara ne verirseniz onu takip ederler. MCP sunucuları bu yürütme metnine metin enjekte eder. Örneğin, “Hangi araçlar var? Bu araçların açıklamaları nelerdir?”
Bu metin LLM davranışını etkileyebilir. Ayrıca, belirli bir API sürümünü kullanabileceğiniz API’lerden farklı olarak, bir MCP ortamında güvenilir sürümleri inceleyemez ve sabitleyemezsiniz. Her bağlantıda MCP istemciniz, MCP sunucusu tarafından sağlanan en son yayınlanan meta verileri alacaktır. Başka bir deyişle MCP, incelemenin hiçbir yolu olmayan, çalışma zamanı tarafından sağlanan metni sağlar. Bir MCP sunucusu ilk bağlantıda zararsız gibi görünse de, güvenilir bir MCP sunucusunun gelecekte kötü amaçlı içerik ekleme olasılığı gizlidir. Buna halı çekme denir. Bu riskler MCP’ye özeldir ve sıradan API güvenlik çerçevelerinin sağlayamayacağı özel çözümler gerektirir.
Güvenlik profesyonelleri ayrıca yanlışlıkla MCP sunucularına kaydolan tüm istemcilere güvenebileceklerini varsayabilir, MCP spesifikasyonunun güncellenmesinin nedeni budur. Dinamik istemci kaydı ve OAuth tek başına her zaman yeterli olmadığından, MCP oluşturucularının ek istemci tanımlama meta verilerini almak için kodlarını güncellemeleri gerekecektir.
Yanlış anlaşılan bir diğer güven modeli de MCP kullanıcılarının satıcı itibarını mimari güvenilirlikle karıştırmasıdır. MCP spesifikasyonu akışa uygun HTTP aktarımını desteklemeye başladığından beri saygın SaaS satıcıları, kullanıcıların daha sonra herhangi bir yerel veya bulut tabanlı MCP istemcisi tarafından çalıştırabilecekleri MCP sunucularını kolayca yayınlayabildi. Ancak ekipler, saygın şirketlerin birinci taraf sunucularının güvenlik açıklarına karşı bağışık olduğunu varsaymamalıdır.
Örneğin araştırmacılar, bu yılın Mayıs ve Haziran aylarında GitHub’un MCP sunucusu ve Atlassian’ın sunucularında anında enjeksiyon güvenlik açıklarını da ortaya çıkardılar. Ayrıca Microsoft Copilot’un hâlâ hızlı enjeksiyon riskiyle karşı karşıya olduğuna dair bir rapor da vardı. Dolayısıyla bu sunucuların hepsinin güvenli olduğunu varsayamazsınız.
Son olarak ve en önemlisi, MCP bir protokoldür (bir ürün değildir). Ve protokoller yerleşik bir “güven garantisi” sunmaz. Sonuçta protokol yalnızca sunucuların ve istemcilerin birleşik bir dil aracılığıyla nasıl iletişim kurduğunu açıklar. MCP, kimlik doğrulama ve kimlik yönetimini, kurumsal operasyonları (örn. denetim izleri, gözlemlenebilirlik, uyumluluk) ve altyapıyı (örn. barındırma, hata işleme, hız sınırlama) çözmez.
Kuruluşlar çok sayıda MCP sunucusunu dahili olarak dağıtmaya başlıyor. MCP yaygın bir entegrasyon dokusu haline geldiğinde hangi yönetişim kör noktaları ortaya çıkıyor ve zayıf yönetişimin operasyonel veya güvenlik sorunları yarattığı bir durumu açıklayabilir misiniz?
Kuruluşlar genellikle merkezi MCP gözlemlenebilirliği ve kontrollerinden yoksundur, bu da güvenlik ekibi üyelerinin görüş alanı dışında ortaya çıkabilecek güvenlik açıklarına daha fazla yer bırakır. Pek çok kuruluşta, MCP sunucularını onaylamak ve yönetmek için süreçlerin ayarlanmasına yönelik bir tablo olan dahili bir MCP kaydı bile yoktur.
Şirketlerin MCP sunucularını onaylayacak ve izleyecek süreçleri olmadığında, hem gölge MCP hem de sunucu yayılımı meydana gelir. Gölge MCP ile çalışanlar, BT’nin hakkında hiçbir şey bilmediği (ve onaylamadığı) sunucuları tanıtıyor. BT/güvenlik ekipleri de uzun vadede bu sunucunun güvenliğini izleyemez (örneğin, bir sunucu iyi bir şekilde başlar ancak daha sonra savunmasız hale gelirse, bu sunucunun bir güvenlik açığına sahip olduğunu fark etseler bile dahili olarak birisinin bunu kullandığını asla bilemezler). Sunucu yayılımı, yinelenen, gereksiz veya kullanılmayan MCP sunucuları sürekli genişleyen bir saldırı yüzeyi oluşturduğunda meydana gelir.
MCP ağ geçitleri, şirketlerin hem gölge MCP’yi hem de sunucu yayılımını azaltan dahili bir kayıt defterine sahip olmalarını sağlar. Dahili kayıtlar, çalışanlara onayların nasıl alınacağını açıklayarak BT ekiplerinin ekiplere araç sağlamasına ve sunucu hazırlamasına olanak tanır.
Kuruluşlarında kötü yönetişimin yıkıma uğramasının ardından MCP ağ geçitleri oluşturmak isteyen çok sayıda ekibe katıldık. Ekiplerin MCP sunucularını korumalı alan oluşturmadan veya güvenli olmayan token depolama, erişim kontrolü ve kapsam belirleme uygulamaları kullanmadan yerel olarak dağıtmasının ardından kendilerini yanmış hisseden güvenlik liderleri gördüm. Yerel MCP sunucuları özellikle tehlikelidir, çünkü cihazdaki hassas kimlik bilgilerine veya dosyalara erişimleri olabilir, MCP.json dosyasında taşıyıcı veya API belirteçleri bulunabilir (bu durum endişe vericidir çünkü bunlar bir makinede bulunan üretim erişim belirteçleridir). Dolayısıyla, dosyaları okuyabilen herhangi bir güvenlik açığı, bunları emebilir ve kötü niyetli bir yere gönderebilir.
Bunlar, güvenlik ekiplerinin karşılaştığı veya öngördüğü ve onların bir MCP yönetişim çözümü aramasına neden olan türde sorunlardır. Çünkü sonuçta kötü yönetişim, dağıtım yöntemlerinde, kimlik doğrulama süreçlerinde ve kimlik yönetiminde tutarsızlığa yol açar; bu da daha geniş kapsamlı risklere neden olabilir ve MCP ekosisteminizin sağlanmasını, gözlemlenmesini ve güçlendirilmesini daha da zorlaştırabilir.
Daha fazla model, MCP araçlarını çağırma yeteneği kazandıkça, yetkisiz aracıların veya sahte bağlamların oluşma riski de artar. Kuruluşların hem MCP sunucusunun hem de çağıran modelin orijinal olduğunu doğrulamak için hangi adımları atması gerekir ve spesifikasyonda hangi korumalar hala eksiktir?
Öncelikle kuruluşların tüm MCP istemcilerini ve sunucularını eklemek için bir inceleme ve onay süreci oluşturması gerekir. Bu, onların tedarik zinciri risklerinden korunmasına yardımcı olacak ve ekip üyelerinin yanlışlıkla kötü niyetli istemcileri ve sunucuları kuruluşa sokma olasılığını azaltabilir.
Güvenlik bilincine sahip kuruluşlar ayrıca tüm MCP sunucularının Kod Değişimi için Proof Key (PKCE) ile birlikte OAuth 2.1 kullanması konusunda ısrar etmeli ve düzenli olarak döndürülen, kapsamı iyi belirlenmiş ve güvenli bir şekilde saklanan belirteçler kullanmalarını sağlayarak yaklaşımlarını güçlendirmelidir. OAuth, MCP spesifikasyonunda önerilen (ancak zorunlu olmayan) kimlik doğrulama akışıdır çünkü diğer, daha temel kimlik doğrulama akışları her zaman zaman kapsamlı değildir ve bu, herhangi bir BT uzmanının isteyebileceğinden daha uzun süre erişim sağlayabilir. Taşıyıcı jetonları (OAuth yerine) kullanmak riskli olabilir çünkü bunlar genellikle bir makinede düz metin olarak depolanır ve yerel bir MCP sunucusunun güvenliği ihlal edilirse kötü amaçlarla kullanılabilir.
Riskler, MCP sunucularındaki araçların adlarından da kaynaklanabilir. Araç adları çok benzerse yapay zeka modelinin kafası karışabilir ve yanlış aracı seçebilir. Kötü niyetli aktörler, Araç Kimliğine Bürünme veya Araç Taklidi olarak bilinen bir saldırı vektöründe bundan yararlanabilir. Saldırganın, kullandığınız başka bir sunucudaki benzer adlı yasal bir araç yerine, yapay zekayı kandırarak kendi kötü amaçlı sunucusuna bir araç eklemesi yeterlidir. Bu, veri hırsızlığına, kimlik bilgileri hırsızlığına, veri bozulmasına ve diğer maliyetli sonuçlara yol açabilir.
Kuruluşunuzda bir MCP ağ geçidinin kullanımını uygulamak ve zorunlu kılmak, aşağıdakileri yapmanızı sağladığı için bu risklerin çoğuna çözüm sağlar:
- Kuruluşunuzun sunucu ve istemci kayıt defterini oluşturun ve yönetin
- Tüm MCP kimlik doğrulama akışlarını standartlaştırın ve sağlamlığını sağlayın
- Uygun jeton rotasyonunu sağlayın
- MCP sunucuları, araçları ve istemcileri için izin verilenler ve engellenenler listeleri oluşturun
- Yapay zeka modelinin doğru aracı seçmesine yardımcı olmak için araçlara ad alanları ekleyin
Uygulayıcıların MCP’yi güvenli bir şekilde çalıştırmak için gereken operasyonel çabayı nerede hafife aldığını düşünüyorsunuz? Gözlemlenebilirlik mi, anahtar yönetimi mi, sunucunun güçlendirilmesi mi veya başka bir şey mi ve ekiplerin hazırlıksız yakalandığı hangi örnekleri gördünüz?
Ekipler, MCP kullanırken güçlü erişim kontrolleri ve izin sınırlarını uygulamanın ne kadar iş gerektirdiğini hafife alıyor. Ayrıca çoğu kurumsal şirketin kimlik yönetimi ve yetkilendirmeyi yönetme biçimi, MCP’nin güvenli, emniyetli ve ölçeklenebilir dağıtım için ihtiyaç duyduğu şeylere her zaman uymaz.
Örneğin, MCP spesifikasyonu, MCP istemcisini bir sunucuya kaydetmek için dinamik istemci kaydı (DCR) gibi işlemlere dayanır. Tüm kimlik doğrulama akışları bunu gerektirmediğinden tüm mühendisler DCR’ye aşina değildir. Ancak daha da önemlisi, kuruluşlar sistemlere, verilere, uygulamalara ve diğer kaynaklara erişmek için anonimleştirilmiş kimlik doğrulama akışları veya paylaşılan “hizmet hesapları” istemezler.
Birlikte çalıştığımız kuruluşlar, MCP’nin mevcut kimlik yönetimi altyapılarına bağlanmasını istiyor. Ayrıca politikalar ve kontrolün yanı sıra hem insan kullanıcılara hem de yapay zeka aracılarına gerçek kimliklerin eklenmesini istiyorlar.
Ancak MCP sunucuları için en temel düzeyde kimlik ve izin yönetimini uygulamak bile çok ağır bir yüktür. Ayrıca, daha fazla dikkat çeken, havalı isimlere sahip çok sayıda gösterişli (ve çok tehlikeli) saldırı vektörü var. Öte yandan kimlik yönetimi karmaşık, yanıltıcı ve yapay zeka modellerinin yetenekleri, MCP kullanım durumları ve MCP spesifikasyonunun kendisi geliştikçe sürekli değişiyor. Bu nedenle kimlik yönetimi sıklıkla gölgede kalıyor ve gözden kaçırılıyor.
Burada bozuk bir plak gibi konuşacağım ama MCP ağ geçitleri burada devreye giriyor. Bir MCP ağ geçidini değerlendirirken, onun uygun kimlik yönetimi sunduğundan emin olun. Ayrıca, ekiplerin ağ geçitlerini, ağ geçidine erişen her kullanıcının MCP sunucuları için kendi kişisel kimlik bilgilerini kullanmasını gerektirecek şekilde sağlamasına olanak tanıyan bir ağ geçidi isteyeceksiniz. Bu, çok fazla erişim sağlayabilecek ve yeterli denetlenebilirlik sağlamayacak, paylaşılan kimlik bilgilerinin veya “bot” / “hizmet” hesaplarının aşırı kullanımını veya kötüye kullanılmasını önler.
MCP’nin benimsenmesi sektörler arasında genişledikçe en önemli yönetişim zorluğu olarak neyi görüyorsunuz ve ortaya çıkan en iyi uygulamalardan hangilerinin gelecek yıl içinde standart hale gelmesini bekliyorsunuz?
MCP’nin benimsenmesi endüstriler ve yetki alanları genelinde genişledikçe, mevzuata uygunluk giderek daha önemli bir yönetişim sorunu haline gelecektir. MCP sunucularının kullanılması veri güvenliği, koruma ve gizlilik konusunda gerçek riskler oluşturur.
Kuruluşların hassas veri kullanımına ve sızdırılmasına karşı sıkı, ayrıntılı erişim kontrolleri ve korkulukları yoksa, bunları uygulama yönünde dış baskının yanı sıra iç baskıyla da karşı karşıya kalacaklardır. Kuruluşların kişisel verilerin, finansal bilgilerin, sağlık kayıtlarının ve diğer yüksek düzeyde düzenlemeye tabi verilerin yapay zeka modelleri tarafından kullanımını özel olarak ele alan yakın gelecekteki mevzuata uymak için önlemler oluşturması veya uygulaması gerekebilir. Bu, verilere yapay zeka tarafından erişilmesini önlemeye yönelik önlemleri veya yapay zekanın erişiminin ve bu bilgilere dayalı eylemlerin denetlenebilir günlüklerini sağlamanın yollarını içerecektir.
MCP sunucularıyla temasa geçen ve bunların kuruluşları üzerindeki etkilerini düşünmeye başlayan herhangi bir güvenlik uzmanının, MCP ağ geçidinin, MCP sunucularını dağıtmak, güvenliğini sağlamak, yönetmek ve izlemek için ihtiyaç duydukları, tartışılamaz ve temel bir araç olduğu sonucuna varacağını düşünüyorum. En iyi paralellik, neredeyse tüm kuruluşların kurumsal e-posta konusunda güçlü çok faktörlü kimlik doğrulama gereklilikleri, anti-spam, anti-phishing ve denetim günlükleri dahil olmak üzere güçlü korumalara sahip olmasıdır. Bu özellikleri sunan bir platform olmadan e-postayı kullanabiliyor olsanız da (uzun yıllardır ekipler bunu yapıyordu), bu gereksiz bir risktir ve artık neredeyse tüm kuruluşlar bu yeteneklere sahip gelişmiş e-posta yazılımları kullanmaktadır. Ekosistem olgunlaştıkça MCP yönetişim platformları da benzer şekilde her yerde bulunacaktır, bu nedenle şirketlerin MCP yönetişim yeteneklerini ne zaman benimseyecekleri meselesidir.
Diğer en iyi uygulamalar açısından, daha büyük kuruluşlar muhtemelen MCP’yi benimsemelerinin başlarında politikaya dayalı erişim kontrollerini benimseyeceklerdir. Politika tabanlı bir yaklaşım benimsemek, ajansal yapay zekanın MCP sunucularını ve kaynaklarını kullandığı öngörülemeyen yöntemlerle daha iyi uyum sağlayan kaynaklara ve izinlere erişimi kontrol etmenin daha ölçeklenebilir, güvenli ve ayrıntılı bir yoludur.
Son olarak, birçok kuruluş halihazırda MCP sunucularını kendi bulutlarında barındırılan dahili hizmetler olarak kullanıyor. Yönetilen MCP dağıtımlarına yönelik bu değişim artacak ve en azından işletmelerde daha az tamamen yerel veya uzak MCP dağıtımları göreceksiniz.