Yetki Kontrollü SAP MCP Server: Araçlar, Yetkilendirme ve Denetim Kayıtları

Bir kullanıcı yapay zekâ asistanına “1000 tesisindeki açık satınalma siparişlerini göster” dediğinde soru basit görünür. Fakat sunucunun cevaplaması gereken asıl sorular başkadır: Bu kullanıcı o tesisi görebilir mi? Fiyat alanına erişebilir mi? İstek hangi SAP sistemine gidecek? Sonuç başka bir konuşmada yeniden kullanılabilir mi?

SAP MCP Server’ı güvenli yapan şey, SAP’ye bağlanabilmesi değildir. Her araç çağrısında kimliği, yetkiyi, hedef sistemi ve veri sınırını yeniden doğrulayabilmesidir.

Bu yazı, çalışan bir demodan üretime uygun bir SAP MCP mimarisine geçerken araçları nasıl ayıracağınızı, yetki kararını nerede vereceğinizi ve denetim izine ne yazacağınızı anlatıyor. MCP’ye giriş arıyorsanız önce SAP MCP nedir? rehberine bakabilirsiniz.

Yetki farkındalıklı SAP MCP Server nedir?

Yetki farkındalıklı bir SAP MCP Server, yalnızca kullanıcının oturum açtığını kontrol etmez. Kullanıcının kimliğini, rolünü, hedef SAP sistemini, istenen aracı, veri kapsamını ve işlemin etkisini birlikte değerlendirir. İzin verilmeyen çağrıyı SAP’ye ulaşmadan durdurur; izin verilen çağrıyı ise SAP tarafındaki yetki kontrollerini koruyarak çalıştırır ve kararı denetlenebilir biçimde kaydeder.

Buradaki önemli ayrım şudur: MCP yetkilendirme tanımı, istemci ile MCP sunucusu arasındaki erişim çerçevesini tarif eder. Bu katman, SAP’nin PFCG rolleri, yetki nesneleri, organizasyon seviyeleri veya uygulamaya özgü kontrollerinin yerini almaz.

Başka bir ifadeyle, geçerli bir erişim belirteci “bu kişi SAP’de her şeyi yapabilir” demek değildir.

Önce tehdit modelini yazın

Araç isimlerini belirlemeden önce kötü gün senaryolarını konuşmak gerekir. Bir SAP MCP Server için en az şu riskleri değerlendirin:

• Kullanıcı, doğal dil kullanarak normalde göremediği şirket kodu veya tesis verisini ister.
• Model, güvenilir görünse de kullanıcının niyetini yanlış yorumlar ve fazla geniş parametre üretir.
• Bir dokümandaki yönlendirici metin, ajanı başka bir aracı çağırmaya ikna eder.
• Geniş yetkili ortak teknik kullanıcı, uygulama katmanındaki küçük bir hatayı SAP genelinde büyük bir erişim sorununa dönüştürür.
• Başarısız görünen yazma çağrısı otomatik tekrarlandığında aynı işlem ikinci kez oluşur.
• Loglar, denetim kanıtı üretirken kişisel veri, belge içeriği veya erişim belirteci sızdırır.

OWASP’nin üretken yapay zekâ güvenliği çalışmalarında da araçların aşırı yetkilendirilmesi, kontrolsüz eylemler ve hassas bilgi ifşası temel risk alanları arasında ele alınır. Güncel sınıflandırmayı OWASP GenAI Security Project üzerinden izlemek yararlıdır.

Tehdit modeli teorik bir belge olarak kalmamalı. Her risk, bir politika kuralına, olumsuz teste ve izleme sinyaline bağlanmalıdır.

Mimari: bir çağrı kaç kontrolden geçmeli?

Üretim çağrısını yedi açık adıma ayırmak, sorumluluğun nerede kaybolduğunu görmeyi kolaylaştırır:

1. Kimliği doğrula. Oturumun geçerli olduğunu, belirtecin doğru hedef kitle ve kapsam için üretildiğini kontrol et.
2. Araç kataloğunu daralt. Kullanıcıya yalnızca rolü, ortamı ve kullanım senaryosu için anlamlı araçları göster.
3. Politika kararı ver. Kullanıcı + araç + hedef sistem + parametre + bağlam birleşimini değerlendir.
4. SAP kimliğini belirle. Destekleniyorsa kullanıcı adına erişim kullan; değilse teknik kimliği dar kapsam ve ek uygulama kontrolleriyle sınırla.
5. Gerekli onayı al. Finansal kayıt, ana veri veya yetki değişikliği gibi etkili işlemleri insan onayı olmadan çalıştırma.
6. Sonucu filtrele. SAP’nin döndürdüğü her alanı modele aktarma; gerekli alanları seç, hassas değerleri maskele ve satır sınırı uygula.
7. Kararı kaydet. Hem izin verilen hem reddedilen çağrılar için yeterli, fakat gereğinden fazla veri içermeyen bir denetim olayı üret.

Bu zincirin yalnızca model isteminde yazması yeterli değildir. “Kullanıcı yetkisizse aracı çağırma” cümlesi bir davranış yönlendirmesidir; güvenlik kontrolü değildir.

Araç tasarımı: küçük, açık ve tek amaçlı

Gerçek MCP araç kataloğu, araç adları ve giriş şemaları ürünün güvenlik ve uygulama tasarımının parçasıdır; kamuya açık bir yazıda paylaşılmaları gerekmez. Temel ilke şudur: Her işlem dar kapsamlı, açık bir iş amacına sahip ve tek etkili olmalıdır. Böylece her işlem için ayrı rol, parametre, onay ve kayıt politikası tanımlanabilir.

Kamuya açık mimari anlatımlarında gerçek adlar yerine “salt okunur sorgu”, “taslak hazırlama” ve “onaylı kalıcı işlem” gibi işlev sınıfları kullanılabilir. Üretimde kullanılan adlar, açıklamalar, şemalar ve SAP nesne eşlemeleri kapalı tutulmalıdır.

Okuma, hazırlama ve uygulamayı ayırın

Tek bir aracın hem veriyi okuyup hem belgeyi oluşturup hem de kaydetmesi cazip gelebilir. Fakat hata anında hangi adımın gerçekleştiğini anlamak zorlaşır. Daha güvenli tasarım üç aşamalıdır:

1. Okuma aracı gerekli bağlamı getirir.
2. Hazırlama aracı değişikliği taslak olarak üretir ve kullanıcıya gösterir.
3. Uygulama aracı onay kimliğiyle birlikte kalıcı işlemi gerçekleştirir.

Özellikle yazma işlemlerinde benzersiz bir tekrar koruması kullanın. Böylece ağ zaman aşımı sonrasında aynı talebin yeniden gönderilmesi ikinci bir belge üretmez.

Parametre alanını daraltın

Bir işlem yalnızca ihtiyacı olan alanları kabul etmelidir. Açık uçlu komut, sorgu veya servis adı almak yerine:

• SAP sistemi ve istemcisini izin listesinden seçin.
• İşlem için gerekli iş alanlarını kapalı ve doğrulanan bir şemayla sınırlandırın.
• Tarih aralığı, satır sayısı ve sayfalama için üst sınır koyun.
• Değiştirilebilecek kayıt türlerini ve alanları sınırlayın.
• Bilinmeyen parametreleri sessizce yok saymak yerine isteği reddedin.

Araç açıklaması modele ne yapacağını anlatır. Giriş şeması ne yapabileceğini daraltır. Sunucu politikası ise ne yapmasına izin verildiğini belirler.

Yetkilendirme kararı nasıl modellenir?

Basit bir rol kontrolü başlangıçtır, son nokta değildir. Karar en az dört bileşeni birlikte değerlendirmelidir:

Örneğin bir satınalma uzmanı salt okunur bir sipariş sorgusu çalıştırabilir; ancak yalnızca yetkili olduğu organizasyon kapsamı için. Aynı kullanıcının kalıcı kayıt işlemi yapabilmesi ise üretim sisteminde ayrı bir onay gerektirebilir.

Mümkün olduğunda SAP çağrısını gerçek kullanıcı bağlamında çalıştırmak, SAP’nin mevcut yetki modelini korur. Ortak teknik kullanıcı zorunluysa o kullanıcıya geniş rol vermek yerine araç bazlı servisleri, hedef sistem izin listesini, organizasyon seviyesi kontrollerini ve kısa ömürlü kimlik bilgilerini birlikte kullanın. Uygulama katmanındaki kontrol, SAP tarafındaki AUTHORITY-CHECK veya ilgili servis yetkilerinin yerine geçmemelidir.

Kavramsal sıra değişmez: önce kimlik ve politika kararı verilir, sonra izin verilen SAP işlemi çalıştırılır, en sonda çıktı filtrelenir ve karar kaydedilir. Bu sıra kamuya açık anlatılabilir; gerçek politika nesneleri, alan adları ve uygulama kodu kapalı kalmalıdır.

İnsan onayı nerede devreye girmeli?

Her çağrı için onay istemek sistemi kullanılmaz hale getirir. Hiç onay istememek ise yüksek etkili kararları modele bırakır. Onay gereksinimini aracın etkisine göre belirleyin:

Onay ekranı “Devam etmek istiyor musunuz?” demekle yetinmemeli. Kullanıcı hangi sistemde, hangi kayıt üzerinde, hangi alanların değişeceğini görmelidir. Onaydan sonra parametre değişirse eski onay geçersiz sayılmalıdır.

Denetim kaydında ne olmalı?

İyi bir audit log, aylar sonra üç soruya cevap verebilir: Kim istedi, sistem neden izin verdi veya reddetti, SAP’de ne oldu?

Her olay için şu alanlar genellikle yeterli bir başlangıçtır:

• Benzersiz olay ve iz kimliği
• Zaman damgası ve ortam
• Kullanıcı veya servis kimliğinin takma adlı referansı
• Kapalı katalogdaki işlem kimliği ve sürümü
• Hedef SAP sistemi ve istemcisi
• Politika kararı ve gerekçe kodu
• Onay gerekiyorsa onay referansı ve karar zamanı
• Parametrelerin hassas veri içermeyen özeti veya özeti alınmış değeri
• SAP yanıt sınıfı, işlem kimliği ve süre
• Uygulanan maskeleme ya da çıktı politikası

Tam kullanıcı istemini, modelin bütün konuşma geçmişini, erişim belirtecini, parolayı veya SAP belgesinin tamamını varsayılan olarak loglamayın. Denetim ihtiyacı ile veri minimizasyonu aynı tasarımın iki parçasıdır.

Logları sonradan değiştirilemeyecek veya değişiklikleri fark edilecek bir depoya göndermek; saat senkronizasyonu, saklama süresi ve erişim rolünü önceden belirlemek de önemlidir. Uygulama logu, SAP değişiklik belgesi ve güvenlik denetim kaydı aynı şey değildir. Ortak bir traceId, bu katmanları gerektiğinde birbirine bağlamalıdır.

Kamuya açık örneklerde gerçek işlem kimliği, hedef sistem adı, gerekçe kodu veya alan şeması gösterilmemelidir. Bu ayrıntılar yalnızca yetkili ekiplerin erişebildiği iç dokümantasyonda tutulmalıdır.

En sık yapılan yedi hata

1. Araç görünürlüğünü yetkilendirme sanmak: Aracı listeden gizlemek iyi bir kullanıcı deneyimidir; sunucu tarafı kontrolün alternatifi değildir.
2. Her çağrıyı ortak geniş yetkili kullanıcıyla çalıştırmak: Küçük bir uygulama hatası, geniş SAP erişimine dönüşebilir.
3. Prompt kurallarına güvenmek: Sistem istemleri aşılabilir veya yanlış yorumlanabilir; politika kodla uygulanmalıdır.
4. Okuma ve yazmayı aynı araçta birleştirmek: Etki sınırı ve onay noktası belirsizleşir.
5. Üretim hedefini modelin seçmesine izin vermek: Sistem, istemci ve ortam sunucu tarafı izin listesinden gelmelidir.
6. Her şeyi loglamak: Denetim izi üretirken ikinci bir hassas veri deposu oluşturulur.
7. Yazma çağrılarını körlemesine tekrar etmek: Zaman aşımı, aynı belgenin iki kez oluşmasına neden olabilir.

Üretime çıkmadan önce test listesi

Yalnızca izin verilen senaryoları değil, reddedilmesi gerekenleri de otomatik test edin:

• Her iş rolü için izin verilen ve reddedilen araçlar
• Şirket kodu, tesis, satınalma organizasyonu ve müşteri gibi veri sınırları
• Geliştirme, test ve üretim hedeflerinin ayrılması
• Süresi dolmuş oturum ve iptal edilmiş kullanıcı
• Eksik, değiştirilmiş veya başka işleme ait onay kimliği
• Prompt injection içeren doküman ve kullanıcı girdileri
• Toplu veri çekme ve sıra dışı sayfalama denemeleri
• Ağ zaman aşımı sonrası yazma çağrısının tekrarı
• Maskeleme sonrası yanıtın hâlâ anlamlı olup olmadığı
• İzin, ret ve hata olaylarında audit kaydının bütünlüğü
• Acil durumda aracı veya hedef sistemi kapatacak kill switch

Testte yalnızca HTTP durum koduna bakmayın. SAP’de işlem oluştu mu, hangi kullanıcıyla oluştu, tekrar çağrıda ne oldu ve denetim olayları birbiriyle bağlanabiliyor mu; bunları birlikte doğrulayın.

SAP Integration Suite bu resmin neresinde?

SAP, Integration Suite içinde MCP Server ve MCP Gateway bileşenleriyle kurumsal API’leri ajanlara açmak için kendi yaklaşımını sunuyor. Ağ geçidi; yayınlama, trafik yönetimi ve güvenlik kontrolleri için önemli bir katmandır. Güncel yetenekler için SAP’nin resmi MCP belgelerini esas alın.

Ancak hangi ürün kullanılırsa kullanılsın temel sorular değişmez: Araç ne yapıyor, hangi kullanıcı adına çalışıyor, hangi SAP verisine erişiyor, ne zaman insan onayı gerekiyor ve geriye hangi kanıt kalıyor?

Kısa cevaplar

MCP, SAP PFCG rollerinin yerine geçer mi?

Hayır. MCP araç keşfi ve çağrı akışını standartlaştırır. SAP’nin kullanıcı, rol, yetki nesnesi ve organizasyon seviyesi kontrolleri çalışmaya devam etmelidir.

Araçları role göre gizlemek yeterli mi?

Hayır. Filtrelenmiş araç kataloğu hata olasılığını azaltır; fakat kötü niyetli veya hatalı doğrudan çağrıya karşı her istekte sunucu tarafı yetkilendirme gerekir.

SAP MCP Server teknik kullanıcıyla çalışabilir mi?

Çalışabilir; ancak kullanıcı adına erişim destekleniyorsa bu tercih edilmelidir. Teknik kullanıcı gerekiyorsa yetkileri dar tutulmalı, iş kullanıcısı bağlamı doğrulanmalı ve her çağrı izlenebilir olmalıdır.

Denetim kaydına kullanıcı sorusunun tamamı yazılmalı mı?

Varsayılan cevap hayırdır. Kararı kanıtlamak için gereken yapılandırılmış alanları kaydedin; kişisel veriyi, erişim bilgisini ve gereksiz iş içeriğini maskeleyin veya hiç saklamayın.

Sonuç: MCP sunucusu bağlantı değil, karar noktasıdır

Üretime uygun bir SAP MCP Server, modele sınırsız SAP erişimi veren bir köprü değildir. Dar amaçlı araçlar, her çağrıda uygulanan politika, SAP tarafındaki yetki kontrolleri, etkili işlemlerde insan onayı ve ölçülü bir denetim izi birlikte çalıştığında güvenilir bir karar noktası oluşur.

NeKu AI SAP MCP Server yaklaşımını ve desteklenen erişim modellerini inceleyebilir; kendi SAP ortamınız için araç ve yetki sınırlarını belirlemek üzere SAP yapay zekâ danışmanlığı ekibiyle görüşebilirsiniz.