SQL Server Güvenlik Sıkılaştırma: Üretim Sunucuları İçin Pratik Kontrol Listesi

SQL Server ortamlarında karşılaştığımız güvenlik olaylarının çok azı, karmaşık bir zero-day açığıyla başlıyor. Çoğunun arkasında çok daha sıradan nedenler var: sysadmin rolüne eklenmiş bir uygulama login’i, ekipte birkaç kişinin bildiği bir sa şifresi, ağın büyük bölümünden erişilebilen 1433 portu ya da ele geçirilen bir hesabın kolayca silebileceği yedekler. Sıkılaştırma (hardening), bu açıkları bir saldırgan fark etmeden önce sistematik olarak kapatma çalışmasıdır.

Bu rehberde SQL Server güvenlik sıkılaştırmasını, üretim ortamlarında bizim de izlediğimiz sırayla ele alıyoruz. İşe mevcut yetkilerin envanterini çıkararak başlıyor, ardından kimlik doğrulama, servis hesapları, saldırı yüzeyi, ağ erişimi, şifreleme, audit, patch yönetimi ve yedeklerin ransomware’e karşı korunması konularına geçiyoruz. Her adımda, mevcut durumunuzu değerlendirebilmeniz için kullanabileceğiniz kontrol sorgularını da paylaşıyoruz.

1. Adım: Değişiklik Yapmadan Önce Yetki Matrisini Çıkarın

En az yetki (least privilege) ilkesini uygulayabilmek için önce bugün kimin hangi yetkiye sahip olduğunu net olarak bilmek gerekiyor. Uzun süredir çalışan sunucularda bu envanter genellikle beklenmedik sonuçlar ortaya çıkarıyor: şirketten ayrılmış çalışanlara ait login’ler, “geçici olarak” eklenip unutulmuş tedarikçi hesapları ya da bir hatayı hızlıca aşmak için sysadmin yapılmış uygulama login’leri bunların başında geliyor.

Çalışmaya sunucu seviyesinden başlamanızı öneriyoruz. Aşağıdaki sorgu, sabit sunucu rollerine üye olan tüm login’leri ve CONTROL SERVER ya da IMPERSONATE ANY LOGIN gibi yüksek etkili yetkilerin doğrudan verildiği hesapları listeler:

-- Sabit sunucu rollerinin üyeleri (sysadmin, securityadmin, ...)
SELECT r.name AS server_role, m.name AS login_name, m.type_desc, m.is_disabled
FROM sys.server_role_members AS rm
JOIN sys.server_principals AS r ON r.principal_id = rm.role_principal_id
JOIN sys.server_principals AS m ON m.principal_id = rm.member_principal_id
WHERE m.name NOT LIKE N'##%'

UNION ALL

-- Doğrudan verilmiş yüksek etkili sunucu yetkileri
SELECT p.permission_name COLLATE DATABASE_DEFAULT, m.name, m.type_desc, m.is_disabled
FROM sys.server_permissions AS p
JOIN sys.server_principals AS m ON m.principal_id = p.grantee_principal_id
WHERE p.permission_name IN (N'CONTROL SERVER', N'IMPERSONATE ANY LOGIN', N'ALTER ANY LOGIN')
  AND p.state IN ('G', 'W')
ORDER BY server_role, login_name;

Sonrasında veritabanı seviyesine geçin. db_owner, db_securityadmin ve db_accessadmin rollerinin üyeleri, ilgili veritabanında kendilerine veya başka kullanıcılara neredeyse sınırsız yetki tanımlayabildiği için bu rollerin ayrıca incelenmesi gerekiyor:

DECLARE @sql nvarchar(max) = N'';

SELECT @sql += N'SELECT ' + QUOTENAME(name, '''') + N' AS database_name,
       r.name AS role_name, m.name AS member_name, m.type_desc
FROM ' + QUOTENAME(name) + N'.sys.database_role_members AS rm
JOIN ' + QUOTENAME(name) + N'.sys.database_principals AS r ON r.principal_id = rm.role_principal_id
JOIN ' + QUOTENAME(name) + N'.sys.database_principals AS m ON m.principal_id = rm.member_principal_id
WHERE r.name IN (N''db_owner'', N''db_securityadmin'', N''db_accessadmin'')
  AND m.name <> N''dbo'' UNION ALL '
FROM sys.databases
WHERE state_desc = N'ONLINE';

SET @sql = LEFT(@sql, LEN(@sql) - 10);   -- sondaki UNION ALL'u at
EXEC sys.sp_executesql @sql;

Elde ettiğiniz sonuçları login adı, kullanım amacı, sorumlu kişi, mevcut roller ve gerçekte ihtiyaç duyulan roller şeklinde basit bir tabloda toplamanızı öneriyoruz. Ortaya çıkan yetki matrisi, sonraki adımların temelini oluşturacak. Bu tabloyu uygulama sahipleriyle de paylaşın; bir login’in hâlâ kullanılıp kullanılmadığını en doğru şekilde onlar teyit edebilir.

Geniş yetkileri, ihtiyaca uygun en dar rolle değiştirin

Bu çalışmada en sık karşılaştığımız bulgular ve önerdiğimiz yaklaşımlar şöyle:

• sysadmin veya db_owner yetkisine sahip uygulama login’leri: uygulamaların büyük çoğunluğu yalnızca veri okuma, yazma ve procedure çalıştırma yetkisine ihtiyaç duyar. Bu yetkileri içeren özel bir veritabanı rolü oluşturabilir ya da db_datareader ve db_datawriter rollerini, ilgili şema üzerindeki EXECUTE yetkisiyle birlikte tanımlayabilirsiniz.
• sysadmin olarak tanımlanmış izleme araçları: izleme araçlarının çoğu için VIEW SERVER STATE yetkisi yeterlidir. SQL Server 2022 ve sonrasında bu yetkileri tek tek vermek yerine ##MS_ServerStateReader## veya ##MS_DefinitionReader## gibi granüler sabit sunucu rollerini kullanmak daha yönetilebilir bir çözüm sunar.
• Kişi bazında tanımlanmış Windows login’leri: bunların yerine Active Directory gruplarını kullanmanızı öneriyoruz. Böylece bir çalışanın görevi değiştiğinde ya da şirketten ayrıldığında, her sunucuda ayrı ayrı işlem yapmak yerine yalnızca grup üyeliğini güncellemeniz yeterli olur.
• Sahibi belirsiz veya kullanılmayan login’ler: sorumlusu tespit edilemeyen login’leri doğrudan silmek yerine önce devre dışı bırakmanızı, en az bir iş döngüsü boyunca etkisini izledikten sonra kaldırmanızı öneriyoruz.

2. Adım: Kimlik Doğrulamayı ve sa Hesabını Güvenli Hale Getirin

Mümkün olan her durumda Windows (Active Directory) kimlik doğrulamasını tercih etmenizi öneriyoruz. Bu yöntemde şifreler dizin hizmetinde tutulur, hesap kilitleme ve şifre politikaları merkezi olarak uygulanır ve ayrılan bir çalışanın hesabı devre dışı bırakıldığında erişimi tüm sunucularda aynı anda sona erer. Mixed mode’u yalnızca bir uygulamanın gerçekten SQL Server login’ine ihtiyaç duyduğu durumlarda açık tutun ve bu durumda tüm SQL login’lerinin Windows şifre politikasına tabi olduğunu doğrulayın:

-- SQL login'leri: politika ayarları ve bariz zayıf şifreler
SELECT name,
       is_disabled,
       is_policy_checked,
       is_expiration_checked,
       PWDCOMPARE(N'', password_hash)  AS empty_password,
       PWDCOMPARE(name, password_hash) AS password_equals_login_name
FROM sys.sql_logins
ORDER BY name;

Sorgu sonucunda is_policy_checked değeri 0 olan, şifresi boş bırakılmış ya da şifresi login adıyla aynı olan hesaplar varsa, önceliği bunlara vermenizi öneriyoruz.

sa hesabı, otomatik saldırı araçlarının ilk denediği login olduğu için aktif olarak kullanılmamalıdır. Hiçbir uygulamanın, job’ın veya linked server’ın bu hesapla bağlanmadığını teyit ettikten sonra hesabı devre dışı bırakabilir, isterseniz adını da değiştirebilirsiniz:

-- Şu anda sa ile bağlı olan var mı? Devre dışı bırakmadan önce kontrol edin.
SELECT session_id, host_name, program_name, login_time
FROM sys.dm_exec_sessions
WHERE original_login_name = N'sa';

ALTER LOGIN [sa] DISABLE;
-- İsteğe bağlı: ALTER LOGIN [sa] WITH NAME = [kimsenin_tahmin_etmeyecegi_bir_ad];

Sahiplik bilgisi login adına değil SID’ye bağlı olduğundan, sahibi sa olan veritabanları ve Agent job’ları bu değişiklikten etkilenmez.

Başarısız login denemelerinin kayıt altına alındığından da emin olmanız gerekiyor. SSMS’te sunucu özelliklerindeki Properties > Security sayfasında Login auditing ayarını en az “Failed logins only” olarak yapılandırabilirsiniz. Error log’da aynı kaynaktan art arda gelen 18456 hataları, çoğu zaman bir brute-force veya password spray girişiminin ilk belirtisidir.

SQL Server 2025 ile birlikte SQL login şifreleri PBKDF2 algoritmasıyla (SHA-512, 100.000 iterasyon) hash’leniyor. Bu değişiklik, ele geçirilen hash’lerin çevrimdışı olarak kırılmasını önemli ölçüde zorlaştırıyor; buna karşılık her SQL login işleminde bir miktar ek CPU maliyeti getiriyor. Connection pooling kullanan uygulamalarda bu fark hissedilmezken, her sorgu için yeni bağlantı açıp kapatan uygulamalarda login süreleri belirgin şekilde uzayabilir. Bu nedenle SQL Server 2025’e geçmeden önce connection pooling yapısının gözden geçirilmesini öneriyoruz.

3. Adım: Servisleri En Az Yetkili Hesaplarla Çalıştırın

Bir saldırgan veritabanı motoru üzerinden kod çalıştırmayı başarırsa, SQL Server servis hesabının sahip olduğu yetkileri devralır. Bu nedenle servis hesabının domain admin, local administrator ya da birden fazla servis tarafından paylaşılan bir hesap olmaması gerekir.

• Virtual account, managed service account veya group managed service account (gMSA) kullanın. gMSA kullanıldığında şifre, servisin yeniden başlatılmasına gerek kalmadan Active Directory tarafından otomatik olarak yenilenir; böylece yönetilmesi ya da sızması gereken bir şifre ortadan kalkar.
• Her servis için ayrı bir hesap tanımlayın. Database Engine, SQL Server Agent, SSIS ve SSRS servislerinin aynı kimliği paylaşmaması gerekir.
• Servis hesaplarını yalnızca SQL Server Configuration Manager üzerinden değiştirin. Bu yöntem, servis SID’lerine bağlı yetkilerin ve dosya erişim izinlerinin doğru şekilde güncellenmesini sağlar.
• Agent job sahiplerini ve proxy tanımlarını gözden geçirin. Servis hesabıyla CmdExec veya PowerShell adımı çalıştıran job’lar, işletim sistemine erişim için gözden kaçabilecek bir yol oluşturur.
• DBA kimliklerini günlük kullanıcı hesaplarından ayırın. SQL Server yönetimi için e-posta ve günlük işlerde kullanılan hesap yerine ayrı bir yönetici hesabı kullanılmalı, sunucuya RDP gibi makine seviyesindeki erişimler ise çok faktörlü kimlik doğrulamayla korunmalıdır.

4. Adım: Saldırı Yüzeyini Daraltın

Etkin durumdaki her özellik, kötüye kullanılabilecek potansiyel bir giriş noktasıdır. Bu nedenle yalnızca gerçekten ihtiyaç duyulan özelliklerin açık olması gerekir. Güvenlik açısından öncelikli olarak incelenmesi gereken ayarları aşağıdaki sorguyla kontrol edebilirsiniz:

SELECT name, value_in_use
FROM sys.configurations
WHERE name IN (N'xp_cmdshell',
               N'Ole Automation Procedures',
               N'clr enabled',
               N'clr strict security',
               N'Ad Hoc Distributed Queries',
               N'cross db ownership chaining',
               N'external scripts enabled',
               N'Database Mail XPs')
ORDER BY name;

Burada önemli bir noktanın altını çizmek gerekiyor: xp_cmdshell‘in kapatılması tek başına yeterli bir koruma sağlamaz, çünkü sysadmin yetkisine sahip herhangi bir kullanıcı bu ayarı tek bir sp_configure komutuyla yeniden açabilir. Bu nedenle asıl kontrol noktası, sysadmin üyeliğinin küçük ve bilinen bir grupla sınırlandırılmasıdır; birinci adımın bu kadar önemli olmasının nedeni de budur.

Bunlara ek olarak her sunucuda iki veritabanı ayarının da kontrol edilmesini öneriyoruz:

-- Kullanıcı veritabanlarında TRUSTWORTHY kapalı olmalı
SELECT name, SUSER_SNAME(owner_sid) AS owner_name, is_trustworthy_on, is_db_chaining_on
FROM sys.databases
WHERE database_id > 4;

-- Her kullanıcı veritabanında: guest bağlanabiliyor mu?
SELECT DB_NAME() AS database_name, permission_name, state_desc
FROM sys.database_permissions
WHERE grantee_principal_id = DATABASE_PRINCIPAL_ID(N'guest')
  AND permission_name = N'CONNECT';
-- Düzeltme: REVOKE CONNECT FROM guest;  (master, msdb ve tempdb'de asla)

Sahibi sysadmin yetkisine sahip bir login olan ve TRUSTWORTHY ayarı açık bırakılmış bir kullanıcı veritabanı, o veritabanında db_owner rolüne sahip herhangi bir kullanıcının sysadmin yetkisi kazanmasına yol açabilir. Belgelenmiş bir bileşen bu ayarı gerektirmiyorsa kapatılması gerekir.

Son olarak kullanılmayan servislerin durdurulup devre dışı bırakılması da saldırı yüzeyini anlamlı ölçüde küçültür. SSRS, SSIS ve Full-Text servisleri ile yalnızca default instance barındıran sunuculardaki SQL Server Browser bu kapsamda ilk değerlendirilmesi gereken servislerdir.

5. Adım: Ağ Erişimini Sınırlandırın

• SQL Server’ı internete açık bırakmayın. İnternetten erişilebilen bir 1433 portu, kısa süre içinde otomatik şifre deneme saldırılarının hedefi haline gelir.
• İzin listesi mantığıyla çalışan bir firewall yapılandırın. SQL portuna yalnızca uygulama sunucuları, ETL ve raporlama sunucuları ile yönetici jump host’ları erişebilmeli; son kullanıcı bilgisayarları dahil diğer tüm kaynaklar engellenmelidir.
• Sabit port kullanın. Her instance için sabit bir port tanımlamak, firewall kurallarının daha net yazılmasını sağlar. İstemciler bağlantı cümlesinde port bilgisini kullanabiliyorsa SQL Server Browser servisini (UDP 1434) kapatabilirsiniz.
• “Hide Instance” ayarını bir güvenlik önlemi olarak değerlendirmeyin. Bu ayar yalnızca Browser servisinin instance’ı duyurmasını engeller; port taraması yapan biri instance’ı yine de tespit edebilir.
• Uzaktan yönetici erişimini bir VPN veya jump host üzerinden, mümkünse kaynak IP adresiyle sınırlandırarak sağlayın.

# SQL Server'a yalnızca uygulama alt ağından ve yönetici jump host'undan izin ver
New-NetFirewallRule -DisplayName "SQL Server 1433 - app and admin only" `
  -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress 10.10.20.0/24, 10.10.99.15 -Action Allow

Ağ erişimini düzenlerken linked server tanımlarını da gözden geçirmenizi öneriyoruz. Tüm yerel login’leri karşı sunucudaki sysadmin yetkili bir hesaba eşleyen bir linked server, tek bir sunucunun ele geçirilmesinin ikinci bir sunucuya da sıçramasına neden olabilir.

6. Adım: Bağlantıları ve Veriyi Şifreleyin

Aktarım sırasında şifreleme

TLS kullanılmayan ortamlarda kimlik bilgileri, sorgular ve sorgu sonuçları ağ üzerinde açık metin olarak taşınır. Bunu önlemek için sunucuya güvenilir bir sertifika otoritesinden alınmış bir sertifika yüklemeniz ve SQL Server Configuration Manager’da Force Encryption ayarını etkinleştirmeniz gerekir. SQL Server 2022 ve sonrasında bunun yerine Force Strict Encryption ayarının kullanılması önerilir. Bu ayar, TLS el sıkışmasının tüm TDS trafiğinden önce gerçekleştiği TDS 8.0 protokolünü devreye alır ve TLS 1.3 kullanımı için de zorunludur. Windows kimlik doğrulaması kullanılan ortamlarda Microsoft, ayrıca Extended Protection ayarının Required olarak yapılandırılmasını öneriyor.

Şifrelemeyi zorunlu hale getirmeden önce mevcut bağlantıların durumunu aşağıdaki sorguyla görebilirsiniz:

SELECT c.client_net_address, s.program_name, s.login_name,
       c.encrypt_option, c.auth_scheme
FROM sys.dm_exec_connections AS c
JOIN sys.dm_exec_sessions    AS s ON s.session_id = c.session_id
ORDER BY c.encrypt_option, c.client_net_address;

encrypt_option değeri FALSE olan bağlantılar, şifreleme zorunlu hale getirilmeden önce güncellenmesi gereken istemcileri gösterir. Bağlantı cümlesinde TrustServerCertificate=True kullanan uygulamalar trafiği şifreler ancak sertifika doğrulamasını atladığı için man-in-the-middle saldırılarına açık kalır. Bu ayarın kalıcı bir çözüm olarak değil, geçiş sürecinde kullanılacak geçici bir yöntem olarak değerlendirilmesi gerekir.

Durağan veride şifreleme: TDE ve yedek şifreleme

Transparent Data Encryption (TDE); data ve log dosyalarını, tempdb‘yi ve yedekleri şifreleyerek çalınan disklerin veya yedek dosyalarının başka bir sunucuda attach ya da restore edilmesini engeller. TDE, Enterprise sürümün yanı sıra SQL Server 2019’dan itibaren Standard sürümde de kullanılabiliyor. SQL Server 2014 ile gelen yedek şifreleme ise yedek dosyalarını bağımsız olarak korur ve TDE’nin uygulanamadığı ortamlarda iyi bir alternatif sunar; ancak Express ve Web sürümlerinde desteklenmez. İki yöntemi birlikte kullanıyorsanız Microsoft, veritabanı ve yedekler için ayrı sertifikalar kullanılmasını öneriyor.

USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = N'<güçlü şifre>';
CREATE CERTIFICATE BackupCert WITH SUBJECT = N'Backup encryption certificate';

-- Sertifikayı ve private key'i HEMEN, farklı bir konuma yedekleyin
BACKUP CERTIFICATE BackupCert
  TO FILE = N'secure-sharekeysBackupCert.cer'
  WITH PRIVATE KEY (FILE = N'secure-sharekeysBackupCert.pvk',
                    ENCRYPTION BY PASSWORD = N'<başka bir güçlü şifre>');

-- Şifreli, sıkıştırılmış, checksum'lı yedek
BACKUP DATABASE SalesDB
  TO DISK = N'B:\Backup\SalesDB_FULL.bak'
  WITH COMPRESSION, CHECKSUM,
       ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = BackupCert);

TC kimlik numarası veya kart numarası gibi hassas kolonlar için Always Encrypted daha güçlü bir koruma sağlar. Şifreleme anahtarları yalnızca istemci uygulamada bulunduğu için veri, veritabanı yöneticilerine karşı da şifreli kalır. Dynamic Data Masking ise yalnızca sorgu sonuçlarında değerleri maskeler; kullanışlı bir özellik olsa da bir güvenlik kontrolü olarak konumlandırılmamalıdır.

7. Adım: Yetkili Kullanıcı Faaliyetlerini Audit Edin ve SIEM’e Aktarın

Sıkılaştırma riski azaltır, ancak her riski ortadan kaldırmaz. Audit ise yetkisiz bir girişim olduğunda bunu fark etmenizi sağlar ve olay sonrası incelemede ihtiyaç duyacağınız kayıtları oluşturur. SQL Server Audit tüm sürümlerde mevcuttur; veritabanı seviyesindeki audit de SQL Server 2016 SP1’den bu yana tüm sürümlerde destekleniyor. Uygulamada iki bileşenden oluşan bir yapıyı başlangıç noktası olarak öneriyoruz.

1. Güvenlik değişiklikleri ve başarısız login denemeleri. Bu olayların hacmi düşük, bilgi değeri ise yüksek olduğu için her sunucuda sürekli açık tutulmalıdır:

USE master;
CREATE SERVER AUDIT [Audit_Security]
  TO FILE (FILEPATH = N'D:\SQLAudit\', MAXSIZE = 256 MB, MAX_ROLLOVER_FILES = 40)
  WITH (ON_FAILURE = CONTINUE);
-- SIEM toplama için TO APPLICATION_LOG veya TO SECURITY_LOG da kullanılabilir

CREATE SERVER AUDIT SPECIFICATION [AuditSpec_Security]
  FOR SERVER AUDIT [Audit_Security]
  ADD (FAILED_LOGIN_GROUP),
  ADD (SERVER_ROLE_MEMBER_CHANGE_GROUP),
  ADD (SERVER_PRINCIPAL_CHANGE_GROUP),
  ADD (SERVER_PERMISSION_CHANGE_GROUP),
  ADD (DATABASE_ROLE_MEMBER_CHANGE_GROUP),
  ADD (DATABASE_PRINCIPAL_CHANGE_GROUP),
  ADD (DATABASE_PERMISSION_CHANGE_GROUP),
  ADD (LOGIN_CHANGE_PASSWORD_GROUP),
  ADD (BACKUP_RESTORE_GROUP),
  ADD (AUDIT_CHANGE_GROUP)
  WITH (STATE = ON);

ALTER SERVER AUDIT [Audit_Security] WITH (STATE = ON);

2. Uygulama dışı kullanıcıların çalıştırdığı sorgular. Uygulama login’leri çok yüksek hacimde sorgu üretirken kullanıcıların doğrudan çalıştırdığı sorgular hem daha az sayıdadır hem de bir olay sonrasında açıklanması gereken işlemler genellikle bunlardır. SQL Server 2022 ve sonrasında BATCH_COMPLETED_GROUP ile batch metninin tamamını kaydedebilirsiniz. Audit’i yalnızca uygulama dışı hesapları kapsayacak şekilde filtrelemek, hacmi kontrol altında tutmanın en pratik yoludur:

USE master;
CREATE SERVER AUDIT [Audit_HumanActivity]
  TO FILE (FILEPATH = N'D:\SQLAudit\', MAXSIZE = 256 MB, MAX_ROLLOVER_FILES = 40)
  WITH (ON_FAILURE = CONTINUE)
  WHERE ([server_principal_name] <> N'AppLogin'
     AND [server_principal_name] <> N'CORP\svc_reporting');

CREATE SERVER AUDIT SPECIFICATION [AuditSpec_HumanActivity]
  FOR SERVER AUDIT [Audit_HumanActivity]
  ADD (BATCH_COMPLETED_GROUP)
  WITH (STATE = ON);

ALTER SERVER AUDIT [Audit_HumanActivity] WITH (STATE = ON);

Batch metinleri hassas veriler içerebileceği için audit dosyalarının da en az veritabanı kadar dikkatle korunması gerekir. Yoğun bir sunucuda bu audit’i etkinleştirmeden önce dosya boyutlarını beklenen hacme göre planlamanızı öneriyoruz.

Audit kayıtlarını okuduğunuzda işlemi kimin, hangi makineden ve hangi uygulama üzerinden yaptığını görebilirsiniz:

SELECT event_time, action_id, succeeded, server_principal_name,
       client_ip, host_name, application_name, database_name, statement
FROM sys.fn_get_audit_file(N'D:\SQLAudit\*.sqlaudit', DEFAULT, DEFAULT)
ORDER BY event_time DESC;

Ancak veritabanı sunucusunda tutulan audit dosyaları, bu dosyaları silebilecek yetkiye sahip kişiler karşısında yeterli güvenceyi sağlamaz. Bu nedenle kayıtların bir SIEM sistemine aktarılması gerekir. Bunun için audit’i Windows Security log’a yazdırabilir ya da dosyaların SIEM ajanı tarafından toplanmasını sağlayabilirsiniz. Security log, müdahaleye en dayanıklı hedeftir; ancak servis hesabının “Generate security audits” hakkına sahip olmasını ve “Application Generated” audit politikasının etkinleştirilmesini gerektirir. Kayıtlar SIEM’e ulaştıktan sonra yeni bir sysadmin üyeliği, durdurulan bir audit ya da kısa sürede art arda gelen başarısız login denemeleri gibi durumlar için alarm tanımlanması önerilir.

8. Adım: Patch Yönetimini Düzenli Hale Getirin ve Desteklenen Sürümde Kalın

SQL Server 2017’den itibaren service pack yayımlanmıyor; güvenlik düzeltmeleri dahil tüm güncellemeler Cumulative Update’ler aracılığıyla sunuluyor. Bu güncellemelerin belirli bir takvime göre, önce üretim dışı bir ortamda test edilerek uygulanması gerekir. Always On ortamlarında güncellemeye secondary replikalardan başlanmalıdır. Güncelleme öncesinde release notlarındaki bilinen sorunları incelemenizi ve ciddi hataları bilinen build’lerden kaçınmanızı öneriyoruz.

Kullanılan sürüm, en az patch seviyesi kadar önemlidir. SQL Server 2016’nın extended support dönemi Temmuz 2026’da sona erdi ve bu tarihten sonra güvenlik güncellemeleri yalnızca ücretli Extended Security Updates programı kapsamında sunuluyor. Desteği sona ermiş bir instance, diğer ayarları ne kadar iyi yapılandırılmış olursa olsun, bu tarihten sonra yayımlanan açıklara karşı korumasız kalır. Saldırıların önemli bir kısmının SQL Server’a işletim sistemi üzerinden ulaştığını düşündüğümüzde, Windows Server güncellemelerinin de aynı disiplinle takip edilmesi gerekir.

9. Adım: Yedekleri Ransomware’e Karşı Koruyun

Ransomware saldırganları, fidye ödemeden sistemleri geri getirmenin yolunun yedeklerden geçtiğini bilir. Bu nedenle çoğu saldırıda önce yedek paylaşımları tespit edilip silinir veya şifrelenir, veritabanları ise ancak bu aşamadan sonra hedef alınır. Ele geçirilen bir domain hesabıyla silinebilen yedekler, böyle bir senaryoda koruma sağlamaz.

• 3-2-1 kuralını uygulayın: en az üç kopyayı, iki farklı ortamda ve biri farklı bir lokasyonda olacak şekilde saklayın. Bu kopyalardan en az birinin değiştirilemez (immutability politikası tanımlı object storage veya WORM depolama) ya da çevrimdışı olması gerekir.
• Yedekleme kimliklerini ayırın: SQL Server servis hesabı yedek yazabilmeli, ancak eski yedekleri silememelidir. Yedek hedefinin, sunucularla aynı domain admin hesaplarına güvenmemesi gerekir.
• Yeterli saklama süresi belirleyin: saldırganlar ağda çoğu zaman haftalarca fark edilmeden kalabildiği için saklama süresinin bir haftanın ötesine uzanması önerilir.
• Restore testlerini düzenli olarak yapın: yedekleri periyodik olarak restore edin ve restore edilen kopyada DBCC CHECKDB çalıştırın. Restore edilmemiş bir yedeğin kullanılabilir olduğundan emin olamazsınız. Ayrıntılar için backup planı rehberimize göz atabilirsiniz.
• Şifreleme anahtarlarını koruyun: şifreli yedeklerin işe yarayabilmesi için ilgili sertifikaların da saldırıdan etkilenmeyecek bir konumda saklanması gerekir.

Deneyimlerimize göre Aryasoft’a yönetilen DBA hizmeti için başvuran müşterilerin önemli bir kısmı, bir ransomware saldırısının ya da büyük bir kesintinin hemen ardından bizimle iletişime geçiyor. Bu ortamlarda tespit ettiğimiz eksikler de çoğunlukla bu rehberde ele aldığımız temel konularla ilgili oluyor: değiştirilemez bir yedeğin bulunmaması, restore testlerinin yapılmaması, gereğinden fazla yetkili hesap olması ve olayın nasıl gerçekleştiğini ortaya koyacak audit kayıtlarının eksikliği. Bu temel kontrollerin bir adım ötesinde, hangi verinin hassas olduğunun ve kimin sorumluluğunda bulunduğunun da bilinmesi gerekir; bu konuyu veri yönetişimi rehberimizde ele aldık.

Önceliklendirilmiş SQL Server Sıkılaştırma Kontrol Listesi

Sıkılaştırma adımlarının her biri aynı düzeyde risk taşımaz. Bu nedenle çalışmaya mevcut sistemi etkilemeyecek adımlarla başlamanızı, test gerektiren değişiklikleri ise planlı bir şekilde ele almanızı öneriyoruz:

Aryasoft bunu nasıl yapıyor?

Her çalışmaya, kendi geliştirdiğimiz ve yalnızca okuma yetkisiyle çalışan HELT360 sağlık taramasıyla başlıyoruz. HELT360, sunucuya ek yük getirmeden yapılandırma kontrolleri yapıyor; çalıştırdığı tüm script’ler panel üzerinden görüntülenebiliyor ve bulgular zaman damgasıyla raporlanıyor. Bu taramanın ardından yetkili kullanıcı ve yetki matrisini müşterimizle birlikte oluşturuyor, düzeltmeleri üretim ortamını aksatmayacak şekilde önceliklendiriyor ve yapılan her değişikliği gerekçesiyle birlikte belgeliyoruz.

Müşteri ortamlarına erişimimizi de aynı güvenlik standartlarıyla yönetiyoruz. Bağlantılar yalnızca şirketimize ait, merkezi olarak yönetilen ve çok faktörlü kimlik doğrulama kullanan ofis bilgisayarlarından yapılıyor. Bu bilgisayarlarda USB depolama cihazlarının kullanımı engelleniyor ve yapılan tüm işlemler kayıt altına alınıyor. Talep edilmesi halinde erişim, IP kısıtlamalı bir VPN bağlantısıyla daha da sınırlandırılabiliyor.