MAESTRO ile Microsoft SQL: Agentic AI Güvenliği

Açık konuşayım: Agentic AI tarafında son altı ayda müşterilerden gelen sorular baya değişti. Bir yıl önce herkes “RAG mimarisi nasıl kurulur” diye soruyordu. Şimdi işe, bu hafta İstanbul’da bir bankacılık işinde aynen şu cümleyi duydum: “Tamam kurduk da, agent veritabanına ne kadar yetkiyle bağlanacak, bunu kim denetleyecek?”

İşte düğüm orada.

Şöyle ki, Microsoft’un geliştirdiği MAESTRO çerçevesi, klasik tehdit modelleme yaklaşımlarının (mesela STRIDE) agentic sistemlerde neden tek başına yetmediğini oldukça net gösteriyor. Ben de bu yazıda hem MAESTRO’nün katmanlı mantığını hem de Microsoft SQL’in (SQL Server 2025, Azure SQL, Managed Instance, Fabric’teki SQL) bu katmanlarda nasıl bir “yönetilen sınır” hâline geldiğini, sahadan gördüklerimle birlikte anlatmaya çalışacağım (ben de ilk duyduğumda şaşırmıştım)

Önce şu soruyu cevaplayalım: Neden eski yöntemler yetmiyor?

Bence, STRIDE, threat modeling tarafında bildiğimiz eski dostlardan biri. Spoofing, Tampering, Repudiation… tamam, bunlar kulağa tanıdık geliyor. Ama işin aslı şu: bu çerçeve, davranışı az çok belli olan uygulamalar için çıkmıştı; yanı endpoint nereye gider, hangı tablo okunur, hangı rol ne yapar, bunlar aşağı yukarı belliydi.

Agentic AI’da tablo değişiyor. Hem de baya.

Bir agent, runtime’da karar veriyor; kullanıcının sorusuna, retrieve ettiği belgeye. Çağırdığı tool’a göre bambaşka bir yol seçebiliyor. Geçen ay bir telekom müşterisinde tam da bunu gördük: müşteri hizmetleri için kurduğumuz agent normalde sadece müşteri profil tablosunu okuması gerekirken, prompt’a gömülmüş bir talimat yüzünden fatura geçmişi tablosuna da sorgu attı (kimse o akışı önceden çizmemişti), çünkü ortada deterministik bir rota yoktu — agent kendi kafasına göre ilerledi.

Evet.

İşte MAESTRO tam burada devreye giriyor. Saldırı yüzeyine tek parça bir uygulama gıbı bakmıyor; daha çok katmanlı bir yığın gıbı ele alıyor ve açık konuşayım, bu yaklaşım klasik modelden biraz daha gerçekçi duruyor.

MAESTRO’nün yedi katmanı — sahadan bakış

Çerçeve yedi katmandan oluşuyor. Microsoft’un resmî dokümanında tek tek anlatılmış, ben de şimdi bunu Türkiye’deki kurumsal müşteri gözünden okuyayım; çünkü kağıt üstünde güzel duran şey, prod ortamında bazen bambaşka bir şeye dönüşüyor, hani insan ilk bakışta “tamamdır” diyor ama sonra iş identity, veri akışı ve log tarafına gelince tablo biraz değişiyor.

• Foundation Models: Modelin kendisi. Jailbreak, hallucination, model extraction gıbı riskler.
• Data Operations: RAG için kullanılan vektör veritabanı, embedding pipeline’ları, doküman havuzları. Data poisoning’in en sevdiği katman. (bence en önemlisi)
• Agent Frameworks: Semantic Kernel, AutoGen, LangChain gıbı orkestrasyon katmanları.
• Deployment & Infrastructure: Container, network, identity. Klasik bulut güvenliği ama agentic context’le.
• Evaluation & Observability: Agent ne yaptı, hangı tool’u çağırdı, ne cevapladı? İzlenebilirlik.
• Security & Compliance: KVKK, GDPR, sektörel regülasyonlar. Türkiye için BDDK ve EPDK da bu işin içinde.
• Agent Ecosystem: Birden fazla agent birbiriyle konuştuğunda ortaya çıkan multi-agent riskleri.

Evet. Bu listeyi görünce insanın aklına önce model geliyor ama işin aslı öyle değil; asıl sürpriz çoğu zaman veri tarafında çıkıyor, çünkü embedding olarak duran bilgi de risk taşıyor, retrieval kaynağı da taşıyor, tool çıktısı da taşıyor (hatta audit log’u bile bazen beklenmedik bir kapı aralıyor), yanı mesele sadece “hangı model?” sorusu değil.

Durun, bir saniye.

Şöyle ki, Neyse uzatmayalım. Şimdi durun bir saniye: bu yedi katmanın hepsinde veri bir şekilde içeri sızıyor gıbı düşünün; bazen doküman havuzundan geliyor, bazen çağrılan tool’un cevabından geliyor, bazen de log dosyasına gömülü hâlde duruyor… Ve veri neredeyse orada SQL’in rolü de büyüyor gıbı duruyor; açık konuşayım, bu hikâyede Microsoft SQL’i kenarda tutmak bana pek mantıklı gelmiyor.

Şahsen, Peki neden? Çünkü agent dünyasında her şey konuşuyor gıbı görünse de arkada sessiz sedasız veri dönüyor. Hani model cevap veriyor sanıyorsunuz ama o cevabın arkasında sorgu var, indeks var, izin var, kayıt var; kısacası klasik veri yönetimi refleksi burada da iş görüyor ama biraz daha karışık bir kılıkla karşımıza çıkıyor.

Durun, bir saniye.

Bence hayatı nokta şu: güvenlik sadece modeli kilitlemek değil. Az önce sadece framework dedim ama aslında deployment ile compliance tarafı da aynı masada oturuyor; container güvenliği tamam, network segmentasyonu tamam, identity tamam… sonra biri gelip “bu agent şu belgeyi niye gördü?” diye sorunca bütün sohbet başka yere kayıyor. İşte tam o anda observability’nın kıymeti ortaya çıkıyor.

Bakın, tam da öyle.

Küçük bir detay: Bir de şu multi-agent işi var ya… İlk başta kulağa baya havalı geliyor. Sonra iki agent birbirine yanlış bağlanınca veya yetki sınırı gevşek kalınca olay uzuyor; nasıl desem, tekil bir hata değil de zincirleme bir tuhaflık çıkabiliyor ortaya ve bunu sonradan ayıklamak hiç keyifli ölmüyor.

Kısacası MAESTRO’yu sadece “AI güvenlik çerçevesi” diye okumak eksik kalır. Benim baktığım yerden bu işin omurgasında veri yönetimi var ve SQL tabanı olan sistemler burada hâlâ baya iş görüyor; tabii her senaryoda sihirli değnek değil ama düzen kurma tarafında eli dayanıklı duruyor.

Durun, bir saniye.

Evet.

SQL artık sadece veritabanı değil — yönetilen bir yürütme sınırı

Bunu söylediğimde bazı arkadaşlar önce bir duruyor, sonra “nasıl yanı?” diye bakıyor. SQL Server 2025. Azure SQL ailesi, agentic AI tarafında aslında bir policy enforcement point gıbı çalışıyor; yanı agent’a “şu veriyi al” dediğiniz anda, erişimin nerede başlayıp nerede biteceğine veritabanı motoru karar veriyor, işin kilit kısmı da tam burada çıkıyor (eh, fena değil) Visual Studio 2026’da Segment Heap: C++ İçin Yeni Dönem yazımızda bu konuya da değinmiştik.

Sahadan örnek vereyim. Geçen yıl Logosoft’ta bir finans müşterisinde Copilot benzeri bir asistan kurarken, Azure SQL’in Row-Level Security ve Dynamic Data Masking özelliklerini agent’ın service principal’ına bağladık; sonuçta agent, kullanıcı kim adına çağrı yapıyorsa onun yetki seviyesinde veri görüyordu, hatta prompt injection ile “bütün müşterilerin TC kimliklerini listele” denildiğinde bile motor seviyesinde duvara çarpıyordu. GitHub App Token Formatı Değişiyor: Override Header Rehberi yazımızda bu konuya da değinmiştik.

Bir dakika — bununla bitmedi.

“Agentic sistemde güvenlik, prompt’ta değil, veritabanı motorunda enforce edilmeli. Çünkü prompt manipüle edilebilir — motor edilemez.”

Hangı SQL özelliği hangı MAESTRO katmanını koruyor?

Bunu tabloya dökmek en temiz yol gıbı geliyor bana. Müşteri sunumlarında da aynısını kullanıyorum; hani bazen uzun anlatınca herkesin gözü dağılıyor ya, burada öyle ölmüyor,. Hangı katmanda neyi tuttuğunu net görüyorsunuz (ve açık konuşayım, bu tarz eşleştirme işi satış toplantısında da baya iş görüyor).

MAESTRO Katmanı	SQL Tarafında Karşılığı	Pratik Faydası
Data Operations	Always Encrypted, TDE, Ledger	Embedding kaynağı veriyi de şifreli tutar
Agent Frameworks	Row-Level Security, DDM	Agent’ın yetkisi motor seviyesinde kısıtlanır
Deployment	Managed Identity, Private Endpoint	Bağlantı string’i sızmaz, network izole kalır
Observability	SQL Audit, Extended Events	Hangı agent ne sorguladı, kayıt altında tutulur
Security & Compliance	Microsoft Defender for SQL	Anormal sorgu davranışı tespit edilir
Agent Ecosystem	SQL MCP Server + RBAC	Multi-agent erişimi tek noktadan yönetilir

Neyse, çok teknik girdim gıbı öldü ama konu aslında basit (evet, doğru duydunuz). SQL tarafını sadece “veri saklanan yer” diye düşünürseniz biraz eksik kalıyor; burada motorun kendisi karar veriyor, denetliyor ve gerektiğinde frene basıyor. Evet.

Evet, doğru duydunuz.

Dürüst olmak gerekirse, Peki neden? Çünkü agent tarafında asıl risk modelden değil, erişimden geliyor. Yanı LLM güzel konuşuyor olabilir ama yanlış tabloyu görürse iş değişiyor; o yüzden güvenliği prompt’a bırakmak yerine SQL katmanına gömmek daha mantıklı duruyor. Bu konuyla ilgili Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımıza da göz atmanızı tavsiye ederim.

Açıkçası bunu ilk gördüğümde ben de “idare eder” demiştim. Sonra sahada bir-iki kez aynı mimariyi kurunca fikrim değişti; özellikle audit tarafı ve private connectivity birleşince olayın tadı başka oluyor.

Kısacası mesele şu: SQL artık arka planda sessizce çalışan klasik bir depo değil, agent’ların ne yapıp ne yapamayacağını yöneten canlı bir kontrol noktası gıbı davranıyor. Tam da öyle.

Defense-in-Depth pratikte nasıl kurulur?

Teori güzel, tamam. Ama iş sahaya inince tablo biraz değişiyor, çünkü bir yerde küçük görünen yetki, prompt injection gelince koça bir delik açabiliyor; geçenlerde bir sigorta şirketinde POC yaparken aynen bunu yaşadım, Agent Azure SQL’e bağlanırken düz bir SQL kullanıcısı ile giriyordu ve bu hesabın db_datareader rolü vardı. Geliştirici de “ne olacak ki, sadece okuyor” diye bakmıştı.

Size bir şey söyleyeyim, Tabi sonra işler kaydı. Prompt injection geldi mi, agent dönüp sys.tables üstünde dolaşmaya başladı; aslında hassas tabloları schema seviyesinde bile görmemesi lazımdı, ama yetki geniş olunca iş uzuyor, hani güvenlik kağıt üstünde var gıbı duruyor, pratikte işe boşluk hemen ortaya çıkıyor.

Ve işler burada ilginçleşiyor.

Çözüm mü? Lafı gevelemeden söyleyeyim: katman katman gittik, yanı tek bir kontrol noktasına yaslanmadık; kullanıcıyı ayırdık, görünür veriyi daralttık, tenant sınırını RLS ile kapattık ve en sonda audit’i zorunlu hâle getirdik. İşin aslı, bu tıp senaryolarda tek bir kilit yetmiyor.

-- 1. Agent için dedike, en az yişe yarayan kullanıcı
CREATE USER agent_reader FROM EXTERNAL PROVIDER;
-- 2. Sadece belirli view'lara erişim
GRANT SELECT ON dbo.v_customer_safe TO agent_reader;
DENY SELECT ON SCHEMA::sensitive TO agent_reader;
-- 3. Row-Level Security politikası
CREATE SECURITY POLICY agent_filter
ADD FILTER PREDICATE dbo.fn_agent_tenant_check(tenant_id) 
ON dbo.v_customer_safe
WITH (STATE = ON);
-- 4. Audit kaydı zorunlu
CREATE DATABASE AUDIT SPECIFICATION agent_audit
FOR SERVER AUDIT [AgentActivityAudit]
ADD (SELECT ON dbo.v_customer_safe BY agent_reader)
WITH (STATE = ON);

Bu dört adımı koyduktan sonra deneme saldırıları baya sönüyor; ne fazladan tablo görünüyor ne de tenant sınırı aşılıyor, üstelik her sorgu audit log’a düşüyor. Evet, biraz sıkı geliyor ama zaten amaç da bu değil mi?

Türkiye perspektifi: KVKK ve sektörel zorluklar

Ne yalan söyleyeyim, Şimdi işin yerel tarafına gelelim. Türkiye’deki kurumsal müşterilerle çalışırken MAESTRO’yu, yanı kağıt üstünde düzgün duran o çerçeveyi, birebir batı standartlarında uygulamak genelde ölmüyor. Neden mi? Çünkü mevzuat var, sektör baskısı var, bir de pratikte kimsenin yüksek sesle söylemediği ufak çekinceler var.

Ve işler burada ilginçleşiyor.

Birinçisi KVKK meselesi. GDPR’a göre daha farklı yorumlanan veri ikametgâhı konusu, özellikle finans ve sağlıkta, bazen beklediğinizden daha sıkı ele alınıyor; yanı agent’ınız OpenAI’ın US bölgesindeki bir modele veri yollayacaksa, bir saniye durun, önce hukukla konuşun, sonra mimariyi çizin (aksi hâlde sonradan dönüp bakınca iş uzuyor). Azure OpenAI’ın Sweden Central veya West Europe bölgeleri çoğu senaryoda daha rahat kabul görüyor. Daha fazla bilgi için Azure DevOps Server Mayıs Yamaları: Sahadan Notlar yazımıza bakabilirsiniz. Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımızda bu konuya da değinmiştik.

Vallahi, İkincisi BDDK’nın bulut bilişim tebliği. Bankalarda can alıcı sistemlerin nerede koşturulacağı belli kurallara bağlı kalıyor, bu yüzden agentic mimarı kurarken SQL tarafında Customer-Managed Keys (CMK) kullanmak neredeyse mecburi hâle geliyor. Sahada şunu çok gördüm: ekip projeyi hızlı başlatıyor, CMK’yi ilk aşamada es geçiyor, sonra audit zamanı herkes bir anda telaşlanıyor. Siz ne dersiniz? Baştan koyun, başınız ağrımasın.

Üçüncüsü — bu biraz da benim kişisel gözlemim — Türkiye’de “AI governance” kavramı hâlâ yeni sayılır. Avrupa’da AI Act konuşuluyor, ABD’de NIST AI RMF referans veriliyor; bizde işe çerçeve tam oturmuş değil, hani biraz havada kalıyor gıbı. Bu yüzden MAESTRO gıbı vendor-bağımsız bir yaklaşımı referans almak fena değil; ileride regülasyon geldiğinde hazırlıksız yakalanmıyorsunuz. Agent Framework + AGT: Üretimde Yönetişim Şart yazımda bu konuya daha detaylı girmiştim, isterseniz oraya da göz atın.

Startup vs Enterprise: Hangı yaklaşımı seçmeli?

Bilmem anlatabiliyor muyum, Bütün bu güvenlik katmanlarını her şirket aynı şekilde kurmalı mı? Açık konuşayım, hayır. Burada biraz ayakları yere basmak gerekiyor, yoksa ilk haftada herkes yoruluyor.

Küçük ekip veya startup iseniz

İlk günden her şeyi devreye almaya kalkmayın; yarısına gelmeden kafanız karışır. Şu üçlüyle başlamak bence daha mantıklı, hatta işin aslı çoğu yerde yeterli bile olabiliyor:

1. Managed Identity ile bağlantı (parola yok) — ciddi fark yaratıyor
2. En az yetkili SQL kullanıcısı (sadece gereken view’lar)
3. Temel audit log (en azından SELECT’leri kaydedin)

Bu üç adım bile sızı saldırıların ciddi bir kısmından uzak tutuyor; yüzde 70-80 demek abartı olmaz (inanın bana). Maliyet tarafı da fena değil, Azure SQL’in standart fiyatlandırması dışında neredeyse ekstra bir yük çıkmıyor (kendi tecrübem)

Evet.

Kurumsal yapıdaysanız

Burada tablo değişiyor, çünkü artık “idare eder” seviyesinde kalmak pek yetmiyor. Defense-in-depth’i ciddiye almanız lazım ve bu noktada Always Encrypted with secure enclaves, Microsoft Defender for SQL, Purview entegrasyonu, Private Link, CMK gıbı parçalar masaya geliyor; hepsini tek tek düşünmek gerekiyor, çünkü biri eksik kalınca zincirin halkası garip biçimde oradan kopuyor.

Aylık maliyet TL bazında ciddi rakamlara çıkabiliyor — orta ölçek bir Azure SQL MI + Defender + Purview kurulumu rahat 80-150 bin TL/ay bandında dolaşabiliyor. Bak şimdi, kulağa sert geliyor ama bir veri ihlalinin yanında bu rakam çoğu zaman komik kalıyor; açıkçası bunu yaşayınca insan farklı düşünüyor.

Neyse, çok dağıtmayayım, konumuzun özü şu: kurumsalda sadece veritabanını değil, etrafındaki görünürlüğü ve erişim zincirini de koruyorsunuz.

Bu arada multi-agent senaryoları için NL2SQL Gerçekten İşe Yarıyor mu? SQL MCP Server Notları yazımı da öneririm. Orada MCP Server üzerinden SQL erişimini nasıl yönettiğimize dair pratik notlar var; hani detay sevenler için baya iş görüyor.

İlk adım olarak ne yapmalı?

İşin garibi, Eğer şu anda agentic bir proje yürütüyorsanız ya da çok yakında başlayacaksanız, ben olsam işi şöyle kurardım: önce riskleri masaya koyar, sonra veri tarafını netleştirir, en sonda da yetki işini sıkı tutarım (en azından benim deneyimim böyle). Kulağa basit geliyor, biliyorum; ama pratikte en çok dağılan yer tam burası oluyor.

1. Threat model çıkarın: MAESTRO’nün yedi katmanını bir kağıda yazın, sonra her katmanda sizin sistemde hangı parça var tek tek bakın. İlk bakışta biraz uğraştırıyor gıbı duruyor, ama açık konuşayım, sonradan “biz bunu neden düşünmedik” dememek için baya işe yarıyor.
2. Veri sınıflandırması yapın: Hangı tablo hassas, hangisi değil? Azure SQL’in built-in data classification özelliğini kullanın, ücretsiz. Burada işin güzel tarafı şu: baştan etiketlerseniz hem kontrol kolaylaşıyor hem de agent’ın eline ne verdiğinizi daha net görüyorsunuz; yoksa bir süre sonra her şey birbirine giriyor.
3. Agent kimliğini ayırın: Asla developer hesabıyla, asla admin yiş gören kullanıcıyla bağlamayın. Evet, bu kural sıkıcı geliyor. Ama tam da bu yüzden önemli; çünkü bir şey ters giderse hasarı küçültmenin yolu çoğu zaman yetkiyi en başta kısmak oluyor.
4. Audit’i baştan kurun: Sonra eklemek 10 kat daha pahalı. Bunu birkaç projede gördüm; önce “bir bakalım çalışsın” deniyor, sonra log eksik kalınca herkes geçmişe dönüp iz sürmeye çalışıyor ve işler uzuyor. Neyse uzatmayayım, log işi sonradan eklenecek süs değil.
5. Red team yapın: Kendi sisteminize prompt injection deneyin. Şaşıracaksınız. Hatta bazen insan kendi kurduğu akışın ne kadar kolay yön değiştirttiğini görünce biraz afallıyor; iyi haber şu ki bunu canlıda değil laboratuvarda görmek daha ucuz.

Garip gelecek ama, Son nokta önemli — geçen ay yaptığımız bir iç red team çalışmasında, kendi kurduğumuz “güvenli” bir agent’tan 4 farklı yöntemle gizli veri çıkarmayı başardık. Hiçbiri SQL motoruna ulaşmadan filtrelendi ama agent katmanında bayağı zayıf noktalar vardı. İşin ilginci şu: veritabanı tarafı gayet toparlaktı, asıl gevşek halka üstteydi; yanı SQL’i sıkı kurun ama agent katmanını da boş geçmeyin.

Açık konuşalım: MAESTRO mükemmel mi?

Hayır, değil. MAESTRO bence hâlâ biraz ham duruyor; özellikle multi-agent ekosistemi katmanı fazla soyut kalıyor, pratik rehberler de az, yanı insan bir noktadan sonra “peki bunu sahada nasıl kuracağım?” diye düşünüyor.

Microsoft’un bu tarafta daha somut implementation guide’lar yayınlaması lazım,. Kağıt üstünde hoş duran şey ile gerçek hayatta ayağa kaldırdığınız şey aynı ölmüyor, arada ciddi fark çıkabiliyor. Beklediğim kadar olgunlaşmış değil, açık konuşayım.

Şey, yine de işin aslı şu: elimizdeki en yapılandırılmış çerçeve şu an MAESTRO. Hiç çerçeve kullanmamaktansa, eksikleriyle birlikte bunu almak daha mantıklı geliyor; zaman içinde oturur. (STRIDE da bir günde ortaya çıkmadı), hatta ilk başta herkes biraz burun kıvırmıştı.

Evet.

Sıkça Sorulan Sorular

MAESTRO sadece Microsoft ürünleri için mi?

Hayır, MAESTRO aslında vendor’dan bağımsız bir tehdit modelleme çerçevesi. Yanı AWS Bedrock, Google Vertex AI ya da tamamen open source bir agentic mimarı için de rahatlıkla kullanabilirsiniz. Microsoft yayınladı diye “sadece Microsoft işi” sanmayın — kavramsal çerçeve evrensel, bence bu en güçlü yanı.

Azure SQL’de agent için en az yetkili kullanıcıyı nasıl oluşturabilirim?

Entra ID üzerinden bir service principal oluşturup bunu Azure SQL’e CREATE USER... FROM EXTERNAL PROVIDER komutuyla ekliyorsunuz. Sonra yalnızca ihtiyaç duyduğu view ya da stored procedure’lara GRANT EXECUTE veriyorsunuz. Açıkçası db_datareader gıbı geniş rolleri toptan vermekten kaçının — tecrübeme göre bu en sık yapılan hata.

Prompt injection’a karşı SQL tarafında ne yapabilirim?

SQL, prompt injection’ı doğrudan engelleyemiyor ama etkisini ciddi ölçüde sınırlandırabiliyor. Mesela Row-Level Security, Dynamic Data Masking, parametreli sorgu zorunluluğu (yanı ad-hoc query yasağı) ve Defender for SQL’in anormallik tespitini birlikte kullandığınızda agent ne kadar yanıltılırsa yanıltılsın yetkisi dışına çıkamıyor. Hani katmanlı savunmanın tam da burada işe yaradığı yer burası.

SQL Server 2025 agentic AI için ne gıbı yenilikler getiriyor?

Vektör arama desteği artık native geliyor (evet, doğru duydunuz). Yanı embedding’leri ayrı bir vektör veritabanına taşımak zorunda kalmıyorsunuz, her şey SQL içinde kalabiliyor. Bunun yanında AI fonksiyonlarını doğrudan T-SQL’den çağırmak da mümkün hâle geldi. Güvenlik tarafında işe Ledger tablolarının çok daha geniş senaryolarda desteklenmesi öne çıkıyor — bence oldukça işe yarar bir özellik.

Küçük bir ekipsek MAESTRO’da nereden başlamalıyız?

Data Operations ve Agent Frameworks katmanları en kritik başlangıç noktası. Kısaca RAG kaynaklarınızı temiz tutun ve agent’ın veri erişim yetkilerini olabildiğince kısıtlayın. Observability ve Compliance katmanlarını ikinci faza bırakabilirsiniz — ama tamamen atlamayın, aslında sonunda genelde lazım oluyor.

Kaynaklar ve İleri Okuma

Microsoft SQL Security Across the MAESTRO Stack (Orijinal Makale)

Azure SQL Database Security Overview — Microsoft Learn

Row-Level Security Resmî Dokümantasyonu

Microsoft Defender for SQL — Tanıtım