MCP Sunucunuz Güvenli. Ancak Arkasındaki Defter Değil.

Unite.AI’de yakın zamanda yayımlanan bir yazıda Gil Feig, güvenli bir MCP sunucusu oluşturmak için altı en iyi uygulamayı sıraladı. Bunlar sağlam öneriler ve MCP sunucusu kullanıma sunan herkes bunları uygulamalı. Her entegrasyona “yalnızca gerekli izinlerle sınırlandırılmış, ayrıntılı ve kendine özgü bir rol” verilmesi yönündeki tavsiyesi son derece yerinde. Ancak bu, diğer uçtaki sistemin de ayrıntılı roller sunduğunu varsayıyor. Bu da nadiren dile getirilen daha kapsamlı bir varsayıma işaret ediyor: Sunucunun arkasındaki sistemlerin de aynı güvenlik standardına göre korunabileceği varsayımına.

İş yazılımlarında bu çoğu zaman mümkün değildir. 32 muhasebe ve ERP sistemine bağlanan, üzerinde isteğe bağlı bir MCP sunucusu da bulunan bir entegrasyon katmanının mühendislik ekibini yönetiyorum. Bizim tarafımızda kimlik doğrulaması, kapsam sınırlaması ve günlük kaydı düzgün yapılmış aracıların, aracıların devrede olduğunu anlamanın hiçbir yolu olmayan sistemlere veri yazdığını düzenli olarak görüyoruz.

Bu yazı, sorunun ikinci yarısını ele alıyor: üst sistemlerin gerçekte neler sunduğunu, entegrasyon katmanından neleri denetleyebileceğinizi ve bu denetimin nerede sona erdiğini.

MCP Spesifikasyonunun Sınır Çizdiği Nokta

Bu MCP yetkilendirme spesifikasyonu kendi sınırları konusunda nettir. MCP sunucusu, istemcileri için bir OAuth kaynak sunucusudur. Üst sistemdeki bir API’yi çağırdığında, ayrı bir OAuth istemcisi olarak hareket eder ve üst sistem tarafından verilen ayrı bir token kullanır. İstemcinin token’ını olduğu gibi iletmek açıkça yasaktır.

Doğru tasarım budur. Ancak bu, üst sistem çağrısıyla ilgili her şeyin, kimin ne yapmasına izin verildiği ve bunun nasıl kaydedildiği de dâhil olmak üzere, tümüyle üst sisteme bağlı olduğu anlamına gelir. Üst sistemin sunmadığı bir özelliği spesifikasyon sağlayamaz.

Aynı durum OWASP’ın aşırı yetkilendirmeye ilişkin rehberi için de geçerli. Rehber, aracının diğer sistemlerdeki uzantılarına verilen izinlerin yalnızca gerekli olanlarla sınırlandırılmasını ve işlemlerin adına hareket ettikleri kullanıcının bağlamında yürütülmesini öneriyor. Her iki öneri de yerinde. Ancak ikisi de diğer sistemin asgari izinleri ve kullanıcı bağlamını ifade edebilecek bir yöntemi olduğunu varsayıyor.

Üst Sistemler Gerçekte Neler Sunuyor?

Bağlandığımız 32 muhasebe ve ERP sistemi, bir entegratörün gözünden şöyle görünüyor:

Üçte birinde hiç OAuth yok

32 sistemin 21’i OAuth kullanıyor. Kalan 11’i ise API anahtarları, kullanıcı adı ve parola ya da bir çift belirteç gibi sabit kimlik bilgilerine dayanıyor. Bu anahtarların bazıları hiç sona ermiyor. Yaygın olarak kullanılan sistemlerden biri, API belirteçlerinin kullanıcı var olduğu sürece sınırsız bir kullanım ömrüne sahip olduğunu belgeliyor.

Uzun Ömür, Kısıtlı İptal İmkânı

OAuth, umduğunuzdan daha az yardımcı oluyor. Sağlayıcılardan biri, yaklaşık 20 yıllık kullanım ömrüne sahip yenileme belirteçleri veriyor. Bu, onu kullanan aracıdan, aracının geliştirildiği çerçeveden ve muhtemelen “İzin ver” düğmesine tıklayan kişiden bile daha uzun süre varlığını sürdürmesi için tasarlanmış bir kimlik bilgisidir. Başka bir sistemde erişim belirteçlerinin bile süresi dolmuyor.

Bir kimlik bilgisi dolaşıma girdikten sonra, onu kimin devre dışı bırakabileceği sorusu ortaya çıkar. Bunun standardı olan OAuth belirteçlerinin iptali (RFC 7009), 2013’ten beri yürürlükte. Buna rağmen, sistemlerin yaklaşık onda dördü entegratörlere kimlik bilgilerini iptal etmek için teknik bir yöntem sunmuyor. API anahtarı kullanan sistemlerin tümü bu grupta. Geriye kalan tek seçenek, müşteriden erişimi elle silmesini istemek.

Kaba Kapsamlar, Aracı Kimliğinin Olmaması

Çoğu sabit anahtar, anahtarı oluşturan kullanıcının tüm yetkilerini devralıyor; yalnızca birkaç sistem anahtarı belirli uç noktalarla sınırlandırmaya izin veriyor. Birçok OAuth sistemi kapsamlar sunuyor, ancak bunlar genellikle “muhasebe, okuma ve yazma” gibi geniş kapsamlı oluyor. Ayrıca, 32 sistemin hiçbirinde API üzerinden aynı işlemde hem aracıyı hem de onun adına hareket ettiği kişiyi kaydetmenin bir yolunu bulabildik. Harici aracılar ya onları bağlayan kullanıcı ya da genel bir sistem kullanıcısı olarak görünüyor. Şaşırtıcı olmayan bir şekilde, bir sağlayıcı kendi ürününe aracılar eklediğinde, Microsoft’ın Business Central’da yaptığı gibi, onlara özel kullanıcı hesapları verdi. Bu, aşağıda önerdiğim modelin aynısı; yalnızca sağlayıcının kendi aracılarına ayrılmış durumda.

Entegrasyon Katmanının Uygulayabilecekleri

Bunların hiçbiri vazgeçmeniz gerektiği anlamına gelmiyor. Aracı ile muhasebe sistemi arasında neredeyse her şeyi denetleyebilirsiniz:

• kendi katmanınıza erişim için her aracıya özel kimlik bilgileri
• örneğin faturalara salt okunur erişim sağlayan kendi kapsamlarınız
• her aracı çağrısını ve aracının adına hareket ettiği kişiyi kaydeden bir denetim günlüğü
• yeniden deneyen bir aracının aynı faturayı iki kez kaydetmesini önleyen idempotensi anahtarları
• aracı başına hız sınırları
• herhangi bir yazma işleminden önce onay adımları

Bunların hiçbiri hedef sistemin sunduğu özelliklere bağlı değil. Entegrasyon katmanında yetkin bir erişim katmanı bugün kurulabilir; finansal verilerin yakınında aracılar kullanıyorsanız böyle bir katman oluşturmalısınız.

Denetimin Sona Erdiği Yer

Yapamayacağınız şey, bu katmanı sistem sınırının ötesine taşımaktır. Bu sınırda üç şey aksar.

İzlenebilirlik

Muhasebe sisteminde, aracının yaptığı kayıt bağlantıya yetki veren kişinin adına ya da teknik bir kullanıcının adına görünür. Sistemi denetleyen herkes, kaydı bu kullanıcının yaptığını görür. Kaydı bir kişinin mi yoksa bir aracının mı oluşturduğunu anlayamaz. Defter açısından, sabah 03.00’te 400 fatura kaydeden bir ajan, son derece çalışkan bir finans yöneticisinden ayırt edilemez. Bunu yeniden ortaya çıkarmak için entegratörün günlüklerine başvurmak gerekir; bu da kayıt sistemininkinden farklı bir güven zinciridir. Adli inceleme veya denetim açısından bu, zayıf bir konumdur.

Kuruluşların çoğu da bu konuda önde değil. Cloud Security Alliance anketinde, katılımcıların yalnızca %28’i tüm ortamlarda ajanların eylemlerini güvenilir biçimde bir kişiye ya da sisteme kadar izleyebildiklerini, %44’ü ise ajanları için statik API anahtarları kullandıklarını veya kullanmayı planladıklarını belirtti.

En az ayrıcalık

Bir ajanın yalnızca faturaları okuyabilmesini sağlayabilirsiniz. Ancak hedef sistemde kapsamlar yoksa, katmanınızın arkasındaki kimlik bilgileri hâlâ tam erişim yetkisine sahiptir. Bu bilgileri ele geçiren herkes katmanınızı ve onunla yazdığınız tüm kuralları tamamen aşabilir.

Erişimi iptal etme

Kendi ajanınızın erişimini anında kesebilirsiniz. Ancak hedef sistemin kimlik bilgileri ele geçirilmişse bu işe yaramaz. İptal uç noktası bulunmayan on sistemden dördünde ise acil durdurma yöntemi müşteriye e-posta göndermektir.

En Pratik Çözüm: Ajan İçin Ayrı Bir Kullanıcı

Bugün yapabileceğiniz en yararlı şey gösterişsiz ama etkilidir. Hedef sistemde ajan için ayrı bir kullanıcı oluşturun ve ajanı yalnızca bu kullanıcı üzerinden bağlayın.

Kullanıcı oluşturmanıza izin veren her sistemde işe yarar ve entegrasyon katmanının sağlayamayacağı üç avantaj sunar:

• Kayıt sisteminde izlenebilirlik. Kayıtlar, altı ay önce “bağlan” düğmesine tıklayan finans yöneticisinin adı yerine “Ödenecek hesaplar ajanı” adıyla görünür.
• API olmasa bile erişimi iptal etme olanağı. Müşteri, kullanıcıyı arayüz üzerinden devre dışı bırakabilir; bu yöntem, iptal uç noktası sunmayan sistemlerde de işe yarar.
• Kısmi en az ayrıcalık. Sistemde herhangi bir rol modeli varsa ajan kullanıcısının erişimi çoğu zaman gerçekten ihtiyaç duyduğu modüllerle sınırlandırılabilir.

Maliyetleri de var. Sisteme alım sırasında birinin kullanıcıyı elle oluşturması gerekir; bu da tam da en uygunsuz anda sürece ek yük getirir. Sistemlerin yaklaşık yarısı, küçük işletmelere yönelik araçlarda ayda birkaç avrodan tam kapsamlı bir ERP’de yüz avronun üzerine kadar değişen ücretlerle her ek kullanıcı için ücret alır. Bazı sistemler ise plana göre kullanıcı sayısını sınırlar; bu nedenle tek bir ek kullanıcı, tüm şirket için daha pahalı bir plan gerektirebilir. Ayrıca sahibi olmayan bir hizmet kullanıcısı başlı başına bir risk oluşturur ve Unite.AI’nin daha önce ele aldığı insan dışı kimliklerin kontrolsüz biçimde çoğalmasısorununun bir parçası hâline gelir. Her hesap gibi bunun da bir sahibi ve gözden geçirme tarihi olmalıdır.

Bu yöntem, kapsamların hiç bulunmadığı sistemlere kapsam özelliği de kazandırmaz. Ancak izlenebilirliği ve erişimi iptal etme olanağını denetçilerin gerçekten baktığı sisteme geri taşır.

Yapısal Çözüm: Yetkilendirilmiş Kimlik

Doğru çözüm kâğıt üzerinde zaten mevcut. OAuth 2.0 Belirteç Değişimi (RFC 8693), başkası gibi davranma ile yetki devrini birbirinden ayırır. Yetki devrinde ajan kendi kimliğini korur ve belirteçteki “act” (eylem) beyanı, bir kişi adına hareket ettiğini kaydeder.

Muhasebeye uygulandığında bunun anlamı şudur:

• defter, bu ajanın bu kişi adına kayıt yaptığını kaydeder
• kapsamlar kullanıcı başına değil, her yetki devri için tanımlanır
• kişinin hesabına dokunmadan tek bir yetki devri iptal edilebilir

Bulabildiğim kadarıyla 32 sistemin hiçbiri buna benzer bir özelliği desteklemiyor. Bu nedenle şimdilik bu, uygulanabilir bir seçenek değil, bir hedef olarak kalıyor. Dolayısıyla bu konu entegratörlere verilecek bir görevden çok muhasebe ve ERP yazılımı sağlayıcılarına yöneltilecek bir talep: ajanlar zaten defterlerinize kayıt giriyor; API’leriniz de bunu belirtebilmeli.

Bir Ajan Deftere Erişmeden Önce Yapılması Gerekenler

Ajanları muhasebe veya ERP sistemlerine bağlıyorsanız, şu kısa kontrol listesini gözden geçirin:

1. Her hedef sistemin kimlik bilgisi modelini inceleyin. OAuth mu, yoksa statik bir anahtar mı kullanılıyor? Kimlik bilgisinin süresi ne kadar? Kapsamları var mı ve erişimi iptal edebiliyor musunuz?
2. Ne olursa olsun kendi erişim katmanınızı oluşturun. Ajan başına kimlik, kapsamlar, idempotentlik ve onaylar, hedef sistemin sunduklarından bağımsız olarak sizin tarafınızda bulunmalıdır.
3. Sistemin izin verdiği her yerde ajan için ayrı bir kullanıcı kullanın. Sistemde kimin işlem yaptığının izlenebilir olması için sisteme alım sürecindeki ek çabayı ve lisans maliyetini göze alın.
4. Kendi denetim kayıtlarınızı, kurcalandığını ortaya koyacak şekilde koruyun. Pek çok sistemde bunlar, bir ajanın sürece dâhil olduğuna ilişkin tek kayıt olacaktır.
5. Artık riski kayda geçirin. Bir sistemde yetkilendirme kapsamları ve erişimi iptal etme mekanizması yoksa bunu hem müşterinize hem de kendi risk kayıtlarınıza açıkça belirtin.

Sınırın Kendisi Kilit Nokta

MCP sunucunuzu güvenceye almak gereklidir, ancak yeterli değildir. Bir deftere yazan ajanın güvenliği, sizin katmanınız ile kayıt sistemi arasındaki sınırda belirlenir; bugün bu sınırı siz değil, sistemler belirliyor.

İyi haber şu ki bu boşluk açıkça tanımlanmış durumda. Standartlar mevcut. Eksik olan, defterleri tutan sistemlerin bu standartları desteklemesi.