SQL Server 2017 “CLR Strict Security” Hatası — Kalıcı Çözüm

Kısa özet: SQL Server 2017 ile birlikte Microsoft, CLR assembly’lerini varsayılan olarak engelleyen yeni bir güvenlik ayarı getirdi (clr strict security = 1). Bu yüzden daha önce sorunsuz çalışan CLR tabanlı uygulamalar (Mikro, Logo, Netsis vb.) SQL 2017’ye geçişte hata vermeye başlar. Aşağıdaki adımlar sorunu kalıcı olarak çözer.

Belirtiler

Bu hatayla karşılaşıyorsanız doğru yerdesiniz:

• CREATE ASSEMBLY failed because assembly ... is not trusted

• The assembly ... could not be loaded because it is not authorized (CLR strict security)

• Mikro/ERP uygulaması açılışta CLR kaynaklı hata veriyor

• SQL 2016’da çalışan bir uygulama SQL 2017’ye geçince bozuldu

Neden Oluyor?

SQL Server 2017’den itibaren clr strict security ayarı varsayılan olarak 1 (açık) gelir. Bu ayar açıkken:

• İmzasız CLR assembly’leri çalıştırılamaz

• SAFE olarak işaretlenmiş olsa bile assembly güvenilir sayılmaz

• Eski uygulamaların CLR bileşenleri devre dışı kalır

Çözüm iki katmanlıdır: sunucu seviyesi ayar + veritabanı seviyesi güven.

Çözüm

Adım 1 — Sunucu Seviyesi Ayarlar

SSMS’te master veritabanına bağlıyken aşağıdaki bloğu tek seferde çalıştırın:

-- Gelişmiş seçenekleri aç (clr strict security'yi görebilmek için gerekli)
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO

-- CLR'yi etkinleştir
EXEC sp_configure 'clr enabled', 1;
RECONFIGURE;
GO

-- SQL 2017'nin katı güvenlik kısıtlamasını kapat
EXEC sp_configure 'clr strict security', 0;
RECONFIGURE;
GO

-- Gelişmiş seçenekleri tekrar kapat (temizlik, opsiyonel)
EXEC sp_configure 'show advanced options', 0;
RECONFIGURE;
GO

⚠️ Bu adımdan sonra SQL Server servisini mutlaka yeniden başlatın. Aksi halde clr strict security değişikliği tam olarak devreye girmez.

Servisi yeniden başlatmak için:

Restart-Service -Name MSSQLSERVER

(Named instance kullanıyorsanız servis adı MSSQL$InstanceAdı şeklindedir.)

Adım 2 — Veritabanı Seviyesi Güven

Sunucu ayarları tek başına yetmezse, ilgili veritabanını “güvenilir” olarak işaretlemek gerekir.

🔴 MikroDB_V15_XXX yazan yeri kendi veritabanı adınızla değiştirin.
🔴 SRV\Administrator yazan yeri kendi SQL login’inizle değiştirin.

-- Veritabanını güvenilir olarak işaretle
ALTER DATABASE MikroDB_V15_XXX SET TRUSTWORTHY ON;
GO

-- Veritabanı sahibini yetkili bir login yap
-- (sp_changedbowner SQL 2012+ sürümlerde kullanımdan kaldırıldı, aşağıdaki daha doğru)
ALTER AUTHORIZATION ON DATABASE::MikroDB_V15_XXX TO [SRV\Administrator];
GO

Doğrulama

Ayarların gerçekten uygulandığını kontrol edin:

EXEC sp_configure 'clr enabled';           -- value_in_use = 1 olmalı
EXEC sp_configure 'clr strict security';   -- value_in_use = 0 olmalı
GO

SELECT name, is_trustworthy_on
FROM sys.databases
WHERE name = 'MikroDB_V15_XXX';            -- is_trustworthy_on = 1 olmalı
GO

Üç değer de beklediğiniz gibi çıkıyorsa sorun çözülmüştür.

Sık Yapılan Hatalar

Güvenlik Notu

clr strict security = 0 ve TRUSTWORTHY ON ayarları, SQL Server’ın CLR için getirdiği ek güvenlik katmanını devre dışı bırakır. Bu ayarlar:

• ✅ Kısa vadede uygulamanızı çalıştırır

• ⚠️ Uzun vadede daha az güvenli bir yapılandırma demektir

Daha güvenli alternatif: Assembly’leri bir sertifika ile imzalamak ve sertifikayı UNSAFE ASSEMBLY yetkisiyle bir login’e bağlamak. Ancak bu, uygulama üreticisinin (Mikro vb.) imzalı assembly dağıtmasını gerektirir. Uygulama üreticiniz imzalı sürüm sunmuyorsa yukarıdaki çözüm pratikte tek seçenektir.

Öneri: Bu ayarları yalnızca uygulamayı çalıştıran sunucuda uygulayın; mümkünse bu sunucuyu diğer iş yüklerinden izole edin.

Özet

1. show advanced options → 1

2. clr enabled → 1

3. clr strict security → 0

4. SQL Server servisini yeniden başlat

5. Hâlâ çalışmıyorsa: TRUSTWORTHY ON + veritabanı sahibini ayarla

Çoğu durumda 1-4 arası adımlar sorunu çözer. 5. adım yalnızca eski/yetki sorunlu veritabanlarında gerekir.

Bu not, SQL Server 2017’ye geçişte CLR tabanlı ERP uygulamalarında yaşanan “strict security” hatası için hazırlanmıştır.