SQL Server DATABASE SCOPED CREDENTIAL Rehberi: Oluşturma, Yetki, Yedekten Dönüş ve Always On

SQL Server’ın dış kaynaklara bağlandığı her yerde bir kimlik bilgisine ihtiyaç vardır: Azure Blob Storage’dan dosya okurken, bir REST API’yi çağırırken, PolyBase ile başka bir veri kaynağına giderken ya da SQL Server 2025’te bir embedding modeline bağlanırken. DATABASE SCOPED CREDENTIAL, bu bilgileri veritabanının içinde şifreli olarak saklar ve kod içine API anahtarı ya da parola yazma ihtiyacını ortadan kaldırır. Ancak master key, yetkilendirme, yedekten dönüş ve Always On gibi konular planlanmazsa production (üretim ortamı) içinde beklenmedik hatalara yol açar.

Bu rehberde DATABASE SCOPED CREDENTIAL’ı uçtan uca ele alıyoruz: ön koşullar, oluşturma, yetkilendirme, secret yenileme, envanter, yedekten başka sunucuya dönüş ve Always On ortamları. Yazıdaki hata mesajları ve sonuçlar, SQL Server 2025 test sunucumuzda yaptığımız denemelerden alındı.

Kısa Özet

DATABASE SCOPED CREDENTIAL Nedir?

DATABASE SCOPED CREDENTIAL, veritabanının dış bir kaynağa bağlanmak için kullandığı kimlik bilgisidir. İki parçadan oluşur: IDENTITY (hesap adı ya da kimlik doğrulama türü) ve SECRET (parola, SAS token, API anahtarı gibi gizli değer). Bir login’e veya veritabanı kullanıcısına bağlı değildir. Veritabanı, dış erişim gerektiren bir işlem yaptığında bu kaydı kullanır.

Secret açık metin olarak saklanmaz; database master key ile şifrelenir. Katalog görünümlerinde yalnızca credential adı ve kimliği görünür, secret hiçbir yoldan geri okunamaz. Bu sayede API anahtarlarını saklı yordam koduna, Agent job adımlarına ya da uygulama yapılandırmasına yazmak zorunda kalmazsınız.

Sunucu Düzeyi Credential ile Farkı

SQL Server’da iki tür credential vardır ve sık karıştırılır:

Veritabanı düzeyinde olması, credential’ın uygulamayla birlikte taşınmasını sağlar. Veritabanını başka bir sunucuya geri yüklediğinizde credential’lar da gelir. Ancak secret’ı çözmek için gereken master key’in yeni sunucuda açılabilmesi gerekir. Bu konuyu aşağıda ayrıca ele alıyoruz.

Nerelerde Kullanılır?

• PolyBase ve veri sanallaştırma: CREATE EXTERNAL DATA SOURCE ile başka bir SQL Server, Oracle, ODBC kaynağı ya da S3 uyumlu depolamaya bağlanırken
• Blob’dan toplu yükleme: Azure Blob Storage’daki dosyaları BULK INSERT ve OPENROWSET(BULK...) ile okurken
• REST API çağrıları: SQL Server 2025’teki sp_invoke_external_rest_endpoint ile API anahtarını başlık veya sorgu parametresi olarak gönderirken
• AI modelleri: SQL Server 2025’te CREATE EXTERNAL MODEL ile Azure OpenAI gibi bir embedding servisine bağlanırken
• Azure SQL Database: elastic query, Extended Events dosyalarını Blob’a yazma ve veri sanallaştırma için

1. Ön Koşul: Database Master Key

Credential’daki secret, veritabanının master key’i ile şifrelenir. Master key yoksa credential oluşturulamaz:

Önce master key’in olup olmadığını kontrol edin, yoksa güçlü bir parolayla oluşturun:

USE SalesDB;
GO
SELECT name, create_date
FROM sys.symmetric_keys
WHERE name = N'##MS_DatabaseMasterKey##';
GO
IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name = N'##MS_DatabaseMasterKey##')
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = N'<guclu-ve-benzersiz-parola>';
GO

SQL Server, master key’i oluştururken ayrıca sunucunun service master key’i ile de şifreler. Böylece aynı sunucuda master key otomatik açılır, parolayı her seferinde yazmanız gerekmez. Master key parolası ise yalnızca veritabanı başka bir sunucuya taşındığında lazım olur. Bu yüzden parolayı kurumsal parola kasasında saklayın ve master key’in yedeğini alın:

BACKUP MASTER KEY TO FILE = N'D:\KeyBackup\SalesDB_dmk.key'
    ENCRYPTION BY PASSWORD = N'<yedek-dosyasi-parolasi>';

2. Credential Oluşturma

Söz dizimi basittir:

CREATE DATABASE SCOPED CREDENTIAL credential_adi
WITH IDENTITY = 'kimlik',
     SECRET = 'gizli-deger';

IDENTITY değeri, credential’ı kullanacak özelliğe göre değişir:

Örnek: REST API Anahtarı

SQL Server 2025’te bir API’yi çağırırken anahtarı koda yazmak yerine credential’a koyun. REST çağrılarında credential adı bir URL olmalı ve çağrılan adresi kapsayan daha genel bir yolu göstermelidir:

CREATE DATABASE SCOPED CREDENTIAL [https://api.example.com/v1]
WITH IDENTITY = 'HTTPEndpointHeaders',
     SECRET = '{"x-api-key":"<api-anahtari>"}';
GO
DECLARE @ret int, @response nvarchar(max);
EXEC @ret = sys.sp_invoke_external_rest_endpoint
     @url = N'https://api.example.com/v1/rates',
     @method = N'GET',
     @credential = [https://api.example.com/v1],
     @response = @response OUTPUT;
SELECT @ret AS http_sonuc, @response AS yanit;

Testimizde SQL Server, credential’daki x-api-key değerini isteğin başlığına kendisi ekledi; anahtar ne kodda ne de çağrı geçmişinde göründü. Özelliğin tamamını SQL Server 2025 ile REST API entegrasyonu yazımızda anlattık.

Örnek: Azure Blob’dan Dosya Yükleme

Blob Storage’daki bir CSV dosyasını yüklemek için önce SAS token içeren bir credential, ardından bu credential’ı kullanan bir dış veri kaynağı tanımlanır:

CREATE DATABASE SCOPED CREDENTIAL BlobImportCred
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
     SECRET = 'sv=2024-11-04&ss=b&srt=co&sp=rl&se=2027-01-01T00:00:00Z&sig=<imza>';
GO
CREATE EXTERNAL DATA SOURCE BlobImports
WITH (TYPE = BLOB_STORAGE,
      LOCATION = 'https://<hesap>.blob.core.windows.net/imports',
      CREDENTIAL = BlobImportCred);
GO
BULK INSERT dbo.DailyOrders
FROM 'orders/2026-11-15.csv'
WITH (DATA_SOURCE = 'BlobImports', FORMAT = 'CSV', FIRSTROW = 2);

FROM içindeki dosya yolu, dış veri kaynağının LOCATION adresine göre yazılır. SAS token’ı yalnızca gereken izinlerle (okuma ve listeleme) ve bir bitiş tarihiyle üretin.

3. Yetkilendirme

Credential üç ayrı yetkiyle yönetilir:

REST çağrısı yapacak bir kullanıcıya EXECUTE ANY EXTERNAL ENDPOINT yetkisi vermek yetmez; kullanacağı credential üzerinde REFERENCES yetkisi de gerekir. Testimizde bu yetki olmadan kullanıcı credential’ı göremedi bile:

Yetkiyi yalnızca ilgili credential için verin:

GRANT REFERENCES ON DATABASE SCOPED CREDENTIAL::[https://api.example.com/v1] TO rest_caller;

REFERENCES yetkisi olan kullanıcı credential’ı kullanabilir ve adını görebilir, ancak secret’ı okuyamaz ve credential’ı değiştiremez. Testimizde aynı kullanıcının ALTER denemesi yine Msg 15151 ile reddedildi. Kimin hangi credential’a yetkisi olduğunu şu sorgu listeler:

SELECT pr.name AS yetkili,
       p.permission_name,
       p.state_desc,
       c.name AS credential_adi
FROM sys.database_permissions AS p
JOIN sys.database_scoped_credentials AS c
    ON p.class_desc = N'DATABASE_SCOPED_CREDENTIAL'
   AND p.major_id = c.credential_id
JOIN sys.database_principals AS pr
    ON pr.principal_id = p.grantee_principal_id
ORDER BY c.name, pr.name;

4. Secret Yenileme (Rotation)

API anahtarları ve SAS token’lar belirli aralıklarla yenilenmelidir. Yenileme ALTER DATABASE SCOPED CREDENTIAL ile yapılır ve bağımlı nesnelere dokunmayı gerektirmez. Dış veri kaynakları ve prosedürler aynı credential adını kullanmaya devam eder:

ALTER DATABASE SCOPED CREDENTIAL [https://api.example.com/v1]
WITH IDENTITY = 'HTTPEndpointHeaders',
     SECRET = '{"x-api-key":"<yeni-api-anahtari>"}';

Testimizde yeni anahtar bir sonraki çağrıda hemen kullanıldı; oturum açıp kapatmak ya da önbellek temizlemek gerekmedi.

Hangi secret’ın ne zaman yenilendiğini modify_date sütunundan izleyebilirsiniz. Şu sorgu 90 günden eski credential’ları listeler:

SELECT name,
       credential_identity,
       create_date,
       modify_date,
       DATEDIFF(DAY, modify_date, SYSDATETIME()) AS gun
FROM sys.database_scoped_credentials
WHERE modify_date < DATEADD(DAY, -90, SYSDATETIME())
ORDER BY modify_date;

5. Envanter: Hangi Credential Nerede Kullanılıyor?

Bir credential’ı silmeden ya da secret’ını değiştirmeden önce neyin ona bağlı olduğunu bilmek gerekir. Dış veri kaynakları ve SQL Server 2025’teki external model’ler credential’ı kimliğiyle tutar:

SELECT c.name AS credential_adi,
       c.credential_identity,
       N'EXTERNAL DATA SOURCE' AS kullanan_tur,
       ds.name AS kullanan_nesne,
       ds.location
FROM sys.database_scoped_credentials AS c
JOIN sys.external_data_sources AS ds ON ds.credential_id = c.credential_id
UNION ALL
SELECT c.name, c.credential_identity, N'EXTERNAL MODEL', m.name, m.location
FROM sys.database_scoped_credentials AS c
JOIN sys.external_models AS m ON m.credential_id = c.credential_id
ORDER BY credential_adi;

REST çağrılarında credential adı prosedür kodunun içinde geçer, bu yüzden yukarıdaki sorguda görünmez. Bunlar için modül tanımlarında arama yapın:

SELECT OBJECT_SCHEMA_NAME(m.object_id) AS sema,
       OBJECT_NAME(m.object_id) AS nesne
FROM sys.sql_modules AS m
WHERE m.definition LIKE N'%@credential%';

Kullanımda olan bir credential’ı silmeye çalışırsanız SQL Server izin vermez:

Önce bağımlı dış veri kaynağını kaldırmanız ya da başka bir credential’a yönlendirmeniz gerekir. REST çağrılarında ise böyle bir koruma yoktur; credential silinirse prosedür ilk çağrıda hata verir.

6. Yedekten Başka Sunucuya Dönüş

Credential veritabanının içinde olduğu için yedekle birlikte taşınır. Sorun, secret’ı çözen master key’in eski sunucunun service master key’i ile şifrelenmiş olmasıdır. Yeni sunucu bu anahtarı otomatik açamaz. Credential listede görünür, ancak ilk kullanımda işlem durur.

Testimizde bu durumu yedekten dönüp master key’in sunucu şifrelemesini kaldırarak canlandırdık. Credential sys.database_scoped_credentials içinde duruyordu; REST çağrısı ise şu hatayı verdi:

Hata mesajı “master key oluşturun” dese de çözüm yeni bir master key oluşturmak değildir. Yeni master key mevcut secret’ları çözemez. Doğru adım, mevcut master key’i parolasıyla açıp yeni sunucunun service master key’i ile de şifrelemektir:

USE SalesDB;
GO
OPEN MASTER KEY DECRYPTION BY PASSWORD = N'<master-key-parolasi>';
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;
CLOSE MASTER KEY;
GO

Bu adımdan sonra master key yeni sunucuda da otomatik açılır ve credential’lar çalışır. Testimizde aynı çağrı bu komutlardan sonra başarılı oldu. Sunucudaki hangi veritabanlarında bu adımın eksik kaldığını şu sorgu gösterir:

SELECT d.name,
       d.is_master_key_encrypted_by_server
FROM sys.databases AS d
WHERE d.database_id > 4
  AND d.is_master_key_encrypted_by_server = 0;

Bu sorgu master key’i olmayan veritabanlarını da listeler; sonuçtaki her veritabanında sys.symmetric_keys içinde ##MS_DatabaseMasterKey## olup olmadığına bakın. Bu kontrolü taşıma ve upgrade runbook’unuza ekleyin. Sunucu taşıma planlaması için SQL Server 2025 upgrade rehberimize bakabilirsiniz.

7. Always On Ortamları

Availability Group’ta credential’lar veritabanıyla birlikte secondary replikalara gider; her replikada ayrıca oluşturmanız gerekmez. Ancak master key primary replikanın service master key’i ile şifrelidir. Failover sonrası yeni primary bu anahtarı kendi service master key’i ile açamaz ve credential kullanan işlemler Msg 15581 ile durur. Secondary veritabanı salt okunur olduğu için yukarıdaki ALTER MASTER KEY adımını önceden orada çalıştıramazsınız.

Bunun için sp_control_dbmasterkey_password kullanılır. Her secondary replikada bir kez çalıştırıldığında master key parolası o sunucunun credential deposuna kaydedilir:

USE master;
GO
EXEC sp_control_dbmasterkey_password
     @db_name  = N'SalesDB',
     @password = N'<master-key-parolasi>',
     @action   = N'add';
GO

SQL Server master key’i service master key ile açamazsa, aynı veritabanı ailesine ait bu kaydı dener. Açmayı başarırsa master key’i yerel service master key ile yeniden şifreler. Test sunucumuzda master key’in sunucu şifrelemesini kaldırıp bu kaydı ekledik: credential sorunsuz çalıştı ve is_master_key_encrypted_by_server değeri kendiliğinden 1’e döndü.

Microsoft bir uyarı da yapar: bu kayıt, sa ve diğer yüksek yetkili hesapların master key’i açmasını sağlar. Master key’i bilerek service master key’den ayırdığınız, sysadmin’lerin bile erişmemesi gereken veritabanları için bu yöntemi kullanmayın. Replikaları güncel tutma ve failover planlaması için SQL Server Always On rehberimize bakabilirsiniz.

8. SQL Server 2025’te Managed Identity

SQL Server 2025, Azure Arc ile bağlanmış sunucularda Microsoft Entra managed identity’yi destekler. Bu durumda credential’da secret bulunmaz; kimlik doğrulamayı sunucunun Azure’daki kimliği yapar ve yenilenecek bir anahtar kalmaz:

EXEC sp_configure 'allow server scoped db credentials', 1;
RECONFIGURE;
GO
CREATE DATABASE SCOPED CREDENTIAL [https://<hesap>.blob.core.windows.net]
WITH IDENTITY = 'Managed Identity';

Bu yöntem için sunucunun Azure Arc’a bağlı ve managed identity’nin etkin olması gerekir. Azure kaynaklarına erişen sunucularda secret yönetmekten kurtulmanın en temiz yoludur. Azure SQL Database ve Managed Instance’ta ise managed identity zaten doğrudan kullanılabilir.

Production İçin Kontrol Listesi

• API anahtarlarını, SAS token’ları ve parolaları koda, job adımlarına veya @headers içine değil, credential’a yazın.
• Master key parolasını kurumsal parola kasasında saklayın ve BACKUP MASTER KEY ile anahtarın yedeğini alın.
• REFERENCES yetkisini kullanıcılara değil rollere ve yalnızca gereken credential için verin.
• SAS token’ları en az izinle ve bitiş tarihiyle üretin; mümkünse managed identity kullanın.
• Secret yenilemeyi takvime bağlayın, modify_date ile yaşını izleyin, yenilemeden hemen sonra test çağrısı yapın.
• Taşıma, upgrade ve felaket kurtarma runbook’larına is_master_key_encrypted_by_server kontrolünü ekleyin.
• Always On replikalarında failover öncesi master key erişimini planlayın.
• Credential oluşturma ve değiştirme işlemlerini SQL Server Audit ile kayıt altına alın.

Sunucu düzeyindeki diğer sıkılaştırma adımları için SQL Server güvenlik sıkılaştırma rehberimize bakabilirsiniz. Credential’ların SQL Server 2025’te embedding modellerine bağlanırken nasıl kullanıldığını ise Azure SQL’de vektör arama yazımızda ele aldık.

Aryasoft ile Credential ve Anahtar Yönetimi

Credential sorunları genellikle oluşturuldukları gün değil, aylar sonra bir taşıma, failover ya da yedekten dönüş sırasında ortaya çıkar. O anda master key parolasını bilen kimse yoksa sorun bir konfigürasyon hatasından veri erişim kesintisine dönüşür. Aryasoft, güvenlik incelemelerinde credential, master key, sertifika ve yetki yapısını birlikte ele alır; parolaların ve anahtar yedeklerinin nerede tutulduğunu belgeler ve taşıma ile felaket kurtarma runbook’larına gerekli kontrolleri ekler.

Sık Sorulan Sorular

Kaynaklar

Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki resmî dokümantasyonla doğrulandı. Hata mesajları ve test sonuçları SQL Server 2025 (17.0.4055.5) test sunucumuzdan alındı.

1. Microsoft Learn: CREATE DATABASE SCOPED CREDENTIAL
2. Microsoft Learn: ALTER DATABASE SCOPED CREDENTIAL
3. Microsoft Learn: sp_control_dbmasterkey_password
4. Microsoft Learn: CREATE MASTER KEY