Active Directory Olmadan SQL Server Kurulumu: Kimlik Doğrulama, Güvenlik ve Workgroup Availability Group

SQL Server’ın çoğu kurulumu bir Active Directory etki alanında yapılır; ama her ortam buna uygun değildir. DMZ’deki sunucular, OT ve üretim sahası ağları, küçük şubeler, bulutta tek başına çalışan sanal makineler ya da güvenlik nedeniyle kurumsal etki alanından bilinçli olarak ayrılmış sistemler bir workgroup sunucusu üzerinde çalışabilir. SQL Server bu ortamlarda da sorunsuz kurulur ve çalışır; ama kimlik doğrulama, servis hesapları ve yüksek erişilebilirlik tarafında bazı şeyler farklıdır.

Bu yazıda etki alanı olmayan bir sunucuda SQL Server kurarken nelere dikkat etmeniz gerektiğini anlatıyoruz.

Kurulum Farkları

Servis hesapları

Etki alanı hesabı ya da group managed service account (gMSA) kullanılamaz; sunucularınız domain üyesiyse daha iyi yol gMSA kurulum rehberimizde anlattığımız yöntemdir. Bunun yerine kurulumun varsayılan önerisi olan sanal hesapları (NT Service\MSSQLSERVER, NT Service\SQLSERVERAGENT) kullanın. Sanal hesaplar yerel olarak yönetilir, parola gerektirmez ve her servis için ayrı bir kimlik sağlar. Servisin ağ üzerindeki bir paylaşıma (örneğin yedek klasörüne) erişmesi gerekiyorsa, aşağıdaki kimlik doğrulama bölümündeki seçenekleri değerlendirin.

Kimlik doğrulama modu

Etki alanı olmadığında diğer makinelerdeki kullanıcıların Windows kimliğiyle bağlanabilmesi pratik değildir. Bu yüzden genellikle Mixed Mode gerekir:

• Uygulamalar için güçlü parolalı, parola politikası uygulanan ayrı SQL login’leri oluşturun.
• sa hesabını devre dışı bırakın; yönetim için ayrı ve adı tahmin edilemeyen bir login kullanın.
• Sunucunun kendisinde oturum açan yöneticiler için yerel Windows grupları üzerinden Windows Authentication kullanmaya devam edebilirsiniz.

Kerberos yok, NTLM var

Etki alanı olmadan Kerberos kimlik doğrulaması kullanılamaz. Bunun pratik sonuçları:

• Windows kimliğinin bir sunucudan diğerine aktarılması (double hop) çalışmaz; linked server’larda ve SSRS gibi ara katmanlarda kullanıcının kimliğiyle bağlanmak mümkün değildir. Bu senaryolarda linked server için açık login eşlemeleri kullanın. Bkz. linked server rehberimiz.
• Eski bir geçici çözüm olarak, iki makinede aynı ad ve parolayla oluşturulmuş yerel Windows hesapları (pass-through kimlik doğrulama) kullanılabilir; ancak parolaların senkron tutulması ve denetlenmesi zordur, kalıcı çözüm olarak önerilmez.

Güvenlik Sertleştirmesi

Etki alanı dışındaki sunucular çoğu zaman daha riskli ağ bölgelerinde durur; bu yüzden sertleştirme daha da önemlidir:

• Güvenlik duvarında SQL Server portunu yalnızca gereken kaynak IP’lere açın; sabit port kullanın ve SQL Server Browser’ı kapatın.
• Yerel yönetici hesaplarını sınırlayın; Group Policy olmadığı için yerel güvenlik ilkelerini (parola politikası, kullanıcı hakları) elle yapılandırın ve belgeleyin.
• Başarısız login denemelerini izleyin ve SIEM’e aktarın. Bkz. SQL Server Audit rehberimiz.
• Yedekleri sunucunun dışına, ayrı kimlik bilgileriyle erişilen bir hedefe alın.

Yüksek Erişilebilirlik: Etki Alanından Bağımsız Availability Group

Windows Server 2016 ve SQL Server 2016 ile birlikte, Windows Server Failover Cluster’lar etki alanı olmadan (workgroup cluster) kurulabilir ve bu cluster’lar üzerinde Always On Availability Group çalıştırılabilir. Bu yapıda:

• Düğümler aynı DNS son ekini (suffix) kullanmalı ve birbirlerinin adlarını çözebilmelidir.
• Cluster, yönetim için aynı ad ve parolaya sahip yerel yönetici hesaplarıyla kurulur.
• Database mirroring endpoint’leri arasındaki kimlik doğrulaması Windows yerine sertifikalarla yapılır.

-- Her replikada: endpoint için sertifika oluşturup diğer replikaya verin
CREATE MASTER KEY ENCRYPTION BY PASSWORD = N'<güçlü parola>';
CREATE CERTIFICATE AG_Node1_Cert WITH SUBJECT = N'AG endpoint certificate - Node1';
BACKUP CERTIFICATE AG_Node1_Cert TO FILE = N'C:\Certs\AG_Node1_Cert.cer';

CREATE ENDPOINT Hadr_endpoint
    STATE = STARTED
    AS TCP (LISTENER_PORT = 5022)
    FOR DATABASE_MIRRORING (AUTHENTICATION = CERTIFICATE AG_Node1_Cert, ROLE = ALL, ENCRYPTION = REQUIRED ALGORITHM AES);

Diğer düğümün sertifikası her replikada içeri alınır ve endpoint’e bağlanma yetkisi bu sertifikayla eşlenmiş bir login’e verilir. Failover cluster instance (FCI) ise paylaşımlı depolama ve etki alanı tabanlı cluster kaynakları gerektirdiği için bu modelde kullanılmaz. Seçenekler için Always On rehberimize bakın.

Kontrol Listesi

• Servisler sanal hesaplarla çalışıyor.
• Mixed Mode kullanılıyorsa parola politikası zorunlu, sa devre dışı.
• Bağlantı şifrelemesi güvenilir bir sertifikayla yapılandırılmış.
• Güvenlik duvarı yalnızca gereken IP’lere ve sabit porta izin veriyor.
• Yerel güvenlik ilkeleri elle yapılandırılmış ve belgelenmiş.
• Yüksek erişilebilirlik gerekiyorsa sertifika tabanlı, etki alanından bağımsız AG planlanmış.