SQL MCP Server ile Kullanıcı Kimliğini Koruyan Denetim

⏱️ 4 dk okuma📅 3 Ağustos 2026

Yapay zeka ajanları veritabanına eriştiğinde kurumsal soru artık “ajanın izni var mıydı?” değil, “hangi kullanıcının izniyle bu işlem yapıldı?” olarak değişiyor. Data API builder (DAB) 2.0 üzerinde çalışan SQL MCP Server, Microsoft Entra ID tabanlı On-Behalf-Of (OBO) kimlik doğrulamasını destekleyerek bu soruya net bir yanıt üretir: Azure SQL denetim kayıtları artık ajanı ya da servisi değil, sorguyu tetikleyen gerçek kullanıcıyı gösterebiliyor.

SQL MCP Server’da üç kimlik doğrulama yaklaşımı

SQL MCP Server tarafında veritabanına bağlanmak için üç temel yöntem var ve her biri denetim kayıtlarına farklı biçimde yansıyor.

Kullanıcı adı ve parola: Popülaritesi azalsa da hala geçerli olan bu yaklaşımda bağlantı dizesindeki kimlik, denetim kayıtlarında operatör olarak görünür. İşlemi kimin başlattığı bilinmez.

Managed Identity (MI): Parola ihtiyacını ortadan kaldırır ama kayıt sonucu değişmez; loglara MCP sunucusunun kimliği düşer, gerçek kullanıcı değil.

On-Behalf-Of (OBO) / pass-through: Microsoft Entra ID ile çalışır. Kullanıcı token’ı ajandan MCP sunucusuna, oradan da Azure SQL’e taşınır. MCP sunucusu bu token’ı aşağı akış token’ıyla değiştirir ve SQL bağlantısı kullanıcı adına açılır. Böylece denetim kayıtları işlemi başlatan gerçek kullanıcıyı işaret eder.

Akış özetle şöyle: Kullanıcı Entra ID ile kimlik doğrular, ajan token’ı MCP sunucusuna iletir, sunucu token değişimi yaparak Azure SQL’e kullanıcı kimliğiyle bağlanır ve SQL, log’a operatör olarak kullanıcıyı yazar.

DAB 2.0 ile OBO yapılandırması

OBO, DAB veri kaynağı bölümünde yapılandırılır. Bağlantı dizesi çıplak bir Azure SQL bağlantı dizesi olmalıdır; User ID, Password veya Authentication alanları yer almaz. DAB, SQL bağlantısını açtığında kullanıcıya özel erişim token’ını enjekte eder.

{
"data-source": {
"database-type": "mssql",
"connection-string": "@env('MSSQL_CONNECTION_STRING')",
"user-delegated-auth": {
"enabled": true,
"provider": "EntraId",
"database-audience": "https://database.windows.net"
}
}
}

Her kullanıcı farklı bir veritabanı bağlantısı aldığı için yanıt önbelleklemesi ile OBO aynı anda kullanılamaz. DAB’ın yapılandırma doğrulayıcısı, ikisini birlikte etkinleştiren yapılandırmaları reddeder. OBO token önbelleği ise kullanıcı bazında tutulur.

Kimliği doğrulamak: WhoAmI örneği

Resmi OBO belgelerinde küçük bir WhoAmI görünümü, aktif bağlantıda SQL’in gördüğü kimliği göstermek için kullanılır:

CREATE VIEW [dbo].[WhoAmI] AS
SELECT SUSER_NAME() AS [UserName];

Bu görünüm DAB üzerinden kimliği doğrulanmış kullanıcılara açılır:

{
"WhoAmI": {
"source": {
"object": "dbo.WhoAmI",
"type": "view",
"key-fields": [ "UserName" ]
},
"rest": {
"enabled": true
},
"permissions": [
{
"role": "authenticated",
"actions": [ { "action": "read" } ]
}
]
}
}

Uygulama tarafında kullanıcı tarayıcıda Entra ID ile oturum açar, taşıyıcı (bearer) token’ı DAB’a iletir, DAB de bu token’ı signed-in kullanıcı için Azure SQL token’ıyla değiştirir:

const headers = await getAuthHeaders();
const response = await fetch(`${API_URL}/api/WhoAmI`, {
method: "GET",
headers
});
const payload = await response.json();
const sqlUserName = payload.value[0].UserName;
console.log(`SQL sees this request as: ${sqlUserName}`);

Sonuçta SQL, isteği bir servis hesabı olarak değil, oturum açan gerçek kullanıcı olarak görür.

Aynı yapılandırma: REST, GraphQL ve MCP

Aynı DAB çalışma zamanı REST, GraphQL ve MCP uç noktalarını birlikte sunabilir. OBO örneğinde MCP, Entra ID kimlik doğrulaması ve kullanıcı-delege yetkilendirmesiyle aynı yapılandırma içinde /mcp yolu üzerinden etkinleştirilir. Bir MCP aracı isteği de aynı WhoAmI varlığını okuyabilir:

{
"tool": "read_records",
"arguments": {
"entity": "WhoAmI"
}
}

Burada temel ayrım netleşir: Eylemi ajan gerçekleştirir ama SQL bu eylemi yetkilendiren kullanıcı bağlamını kaydeder. DAB varlık izinlerini uygulamaya devam eder, Azure SQL ise isteğin arkasındaki kullanıcıyı doğrular.

Azure SQL denetimi ve Log Analytics

Azure SQL denetimi veritabanı olaylarını Blob storage, Event Hubs veya Log Analytics’e yazabilir. Denetim şemasında database_principal_name, server_principal_name, statement ve OBO ile bağlanan orta katman uygulamasını tanımlayan obo_middle_tier_app_id gibi alanlar bulunur.

Log Analytics’te SQL’in gördüğü kullanıcıyı listelemek için şu tarz bir sorgu kullanılabilir:

AzureDiagnostics
| where Category == "SQLSecurityAuditEvents"
| where database_name_s == ""
| project
event_time_t,
action_name_s,
database_principal_name_s,
server_principal_name_s,
obo_middle_tier_app_id_s,
statement_s
| order by event_time_t desc

Bu sorgu kullanıcıyı, gerçekleştirilen SQL eylemini, çalıştırılan ifadeyi ve OBO yolundaki orta katman uygulamayı tek görünümde toplar. Ortaya çıkan tablo, ajan tabanlı sistemler için daha güçlü bir denetim sınırı oluşturur.

Ajan erişimini hesap verebilir kılmak

Basit uygulamalarda yönetilen kimlik veya servis kimlik bilgisiyle bağlanmak yeterli olabilir. Hassas verilere dokunan kurumsal ajanlarda ise veritabanının gerçek çağıranı bilmesi gerekir. SQL MCP Server ve DAB’ın OBO desteği tam da bu boşluğu doldurur: Ajan araçları çağırır, DAB izinleri uygular, Azure SQL ise “bunu kim yaptı?” sorusuna yanıt verebilir.

Kaynaklar ve İleri Okuma

Bu yazı yapay zeka (büyük dil modelleri) ile hazırlanmış, insan editör tarafından incelenmiştir. İçerik üretim sürecimiz.

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102