SQL Server günlük gönderimi için güvenliği yapılandırma

  • Makale

Bu makalede, SQL Server günlük gönderimi için güvenliğin nasıl yapılandırıldığı açıklanır ve SQL Server günlük gönderimi için güvenliği yapılandırırken oluşabilecek sorun hakkında bilgi sağlanır.

Özgün ürün sürümü: SQL Server
Özgün KB numarası: 321247

Özet

Bu makalede günlük gönderimi için güvenliği yapılandırma hakkında bilgi verilmektedir. SQL Server günlük gönderimi için güvenliği yapılandırırken, işlem günlüğü yedeklemelerinin bulunduğu ağ paylaşımının izinlerini paylaşmaya SQL Server için başlangıç hesabından başlayarak dikkate alınması gereken birkaç sorun vardır. Bu sorunlar bu makalede açıklanmıştır.

Etki alanı hesabı

SQL Server bir etki alanına yerleştirdiyseniz Microsoft, SQL Server hizmetlerini başlatmak için bir etki alanı hesabı kullanmanızı önerir. SQL Server Windows Kümelemesi altında Sanal sunucu olarak çalışacak şekilde yapılandıracaksanız bir etki alanı hesabı kullanmalısınız. Etki alanı hesabı, parola değişiklikleri durumunda minimum bakım avantajı sağlar. Ancak, SQL Server çalışma grubundaki bir sunucuda bulunuyorsa SQL'i bir etki alanı hesabı altında başlatamayabilirsiniz.

Yerel ağ hesabı

yerel olarak oluşturulan bir ağ hesabı altında başlamak için SQL Server kullanabilirsiniz. bir SQL Server işleminin gerektirdiği ağ erişiminin olması durumunda, günlük gönderimini kullanmak üzere SQL Server yapılandırdıysanız ağ geçiş güvenliğini kullanabilirsiniz. Doğrudan güvenlik sayesinde, SQL Server tarafından erişilecek tüm makinelerin aynı parolaya ve yerel olarak yapılandırılmış uygun izinlere sahip aynı ağ hesabına sahip olması gerekir. Ayrıca, SQL Server işlemi ikinci bilgisayardan kaynak istediğinde, aynı hesap (istekte bulunan SQL Server hizmetinin başlatıldığı) aynı parolayla varsa geleneksel ağ güvenliği atlanır. İkinci bilgisayardaki hesap, SQL Server çağrılarak istenen görevi gerçekleştirmek için yeterli izinle yapılandırıldığı sürece, görev başarılı olur.

Yerel sistem hesabı

Ayrıca SQL Server Yerel Sistem hesabı altında başlatacak şekilde yapılandırabilirsiniz. LocalSystem hesabının parolasının değiştirilmesi, sistem kararlılığı açısından kritik olan bazı hizmetlerin başarısız olmasıyla sonuçlanabilir. Bu hesap, bulunduğu bilgisayarda yereldir, yani SQL Server hizmetlerin kullandığı güvenlik bağlamı yereldir. Yerel Ağ Hesabı bölümünde belirtildiği gibi, farklı bilgisayarlardaki LocalSystem hesabının parolaları farklı olduğundan LocalSystem hesabı altında SQL Server başlattığınızda ağ geçiş güvenliğini kullanamazsınız. Ağ kaynağı erişimi gerektiğinde bu hesap altında SQL Server başlatılması büyük olasılıkla görevlerin başarısız tamamlanmasına neden olur.

Bir ağ hesabının SQL Server ve SQL Server Agent hizmetlerini başarıyla başlatıp çalıştırması için gereken en düşük haklar hakkında bilgi için bkz. Windows Hizmet Hesaplarını Ayarlama.

SQL Server güvenlik modelini anlama

Güvenlik etkilerini tamamen anlamak için Microsoft'un SQL Server 2000'de uyguladığı güvenlik modelini anlamak önemlidir. Bir oturum açma oluşturduğunuzda, master veritabanındaki tabloya syslogins eklenir. Yeni eklenen bu oturum açma bilgilerinin sağlandığı her veritabanı için bu veritabanındaki sysusers tabloya eklenir. Tablo ve sysusers tablo arasındaki syslogins eşleme SID alanındadır.

Kullanıcı veritabanı farklı bir sunucuya taşınırsa, SID değerleri önceki sunucudan taşınır. İkinci sunucudaki oturum açma işlemleri aynı SID değerleriyle oluşturulmadığında veya sid değerlerinin eşleşmemesi nedeniyle güvenlik yanlış yapılandırıldığında veritabanı güvenlik sonları.

Daha fazla bilgi için bkz. SQL Server çalıştıran sunucular arasında veritabanı taşırken karşılaşılan izin sorunlarını çözme.

Güvenlik gereksinimleri

  • Yedekleme Paylaşımı

    İşlem günlüğü yedeklemelerini tutacak şekilde yapılandırılan ağ paylaşımını, SQL Server hizmetlerinin (günlük gönderimi için yapılandırılmış ikincil sunucuda) başlatıldığı hesap için okuma/değiştirme izinlerine sahip olacak şekilde yapılandırın.

    İşlem günlüğü yedeklemelerini barındıracak şekilde yapılandırılan ağ paylaşımı, günlük gönderimi için yapılandırılmış ikincil sunucuda SQL Server hizmetlerinin başlatıldığı hesap için okuma/değiştirme izinlerine sahip olacak şekilde yapılandırılmalıdır. bu paylaşıma, işlem günlüğü yedeklerini ilgili ikincil sunucudaki yerel klasöre kopyalamak için ikincil sunucudaki Kopyalama işi tarafından erişilir. Yükle işi daha sonra bu yedeklemeleri yerel klasörden yükler.

  • Etki Alanları Arası Günlük Gönderimi

    SQL Server çalıştıran bilgisayarlar çok etki alanılı bir ortama yerleştirilirse, Microsoft günlük gönderiminde yer alan tüm etki alanları arasında iki yönlü güvenler ayarlamanızı önerir. Ancak, etki alanları arasında güven oluşturamıyorsanız, günlük gönderimi için ağ geçiş güvenliğini kullanabilirsiniz. SQL Server ilgili hizmetler için LocalSystem ağ hesabı başlatma seçeneğinin açıklandığı bu makalenin bölümüne bakın.

  • İzleyici Sunucusuna Bağlanmak için Kimlik Doğrulama Modunu Seçme

    İzleme sunucusuna bağlanmak ve izleyici tablolarını güncelleştirmek için Windows kimlik doğrulamasını veya SQL kimlik doğrulamasını (birincil ve ikincil sunuculara göre) seçebilirsiniz. Bunu, günlük gönderimini ayarlarken veya günlük gönderimini ayarladıktan sonra seçebilirsiniz. Varsayılan olarak, SQL Server Windows kimlik doğrulamasını kullanır; ancak SQL kimlik doğrulamasını seçerseniz, birincil, ikincil ve yoksa izleme sunucularında yeni bir SQL oturum açma log_shipping_monitor_probe oluşturulur. Bu amaçla SQL kimlik doğrulaması'nı seçerseniz SQL Server SQL ve Windows kimlik doğrulaması seçeneğini kullanacak şekilde yapılandırın.

Bekleyen Veritabanları için ikincil sunucuda güvenlik yapılandırması

İkincil veritabanını bekleme modunda yapılandırdıysanız, bu veritabanına salt okunur durumda erişebilirsiniz. Bu, ikincil veritabanını bu modda geri yükleyerek çevrimdışı raporların çalıştırıldığı bir araç sağlayabilir ve böylece işin bir kısmını üretim sisteminden boşaltabilir. Ancak, hazır bekleyen veritabanının salt okunur işlevselliği desteklemesi için ikincil sunucuya aynı güvenlik ayarlarını uygulamanız gerekebilir. Veritabanı bekleme durumunda olduğundan, güvenliği yapılandırma amacıyla değişiklik bile yapamazsınız. Bu durumda, ikincil sunucuda aynı SID değerlerine sahip tüm SQL Server oturum açma bilgilerini oluşturmanız gerekir. Windows GUID birden çok etki alanı kullanırken bile genel olarak benzersiz olduğundan Windows oturum açma işlemleri otomatik olarak aynı SID'leri korur.

Farklı sunucularda aynı SID ile SQL oturum açma bilgileri oluşturma hakkında daha fazla bilgi için bkz. SQL Server'da konuk devre dışı bırakıldığında bekleme veritabanındaki SQL oturum açma bilgilerine erişim verme.

Rol değişikliği yaparken güvenlik yapılandırması

Günlük gönderimi için rol değiştirme yordamı, ikincil bir sunucunun birincil sunucu olarak devralılmasını gerektirir. Bunu birincil sunucu çevrimiçi veya çevrimiçi olmadan yapabilirsiniz. Rol değişikliğinin bir parçası olarak, yürütülen en fazla dört saklı yordam vardır. Bu saklı yordamlardan biri olan , sp_resolve_logins hazır bekleyen veritabanında bulunan oturum açma bilgilerinin SID değerlerinin birincil veritabanı olarak kullanıma sunulmadan hemen önce düzeltilmeye yardımcı olur.

Bu saklı yordamın bir parçası olarak, eski birincil sunucudan syslogins tablonun bir .bcp dosyası geçici bir tabloya yüklenir. Bu geçici tabloda bulunan her oturum açma işlemi, ikincil sunucunun syslogins MASTER veritabanındaki tabloyla ve sysusers ikincil veritabanının tablosuyla karşılaştırılır. Tabloda aynı ada syslogins ve ikincil veritabanının tablosundakiyle aynı SID'ye sahip olan geçici tablodaki sysusers her oturum açma için, SID tablosundakiyle eşleşecek syslogins şekilde kullanılarak sp_change_users_login düzeltilir (ikincil veritabanında).

Bu saklı yordamı kullanan güvenlik yapılandırması için şunlar gerekir:

  • SQL oturum açma işlemleri ikincil sunucuda zaten oluşturulmuş olmalıdır. Bunu yapmak için, SQL Server Books Online konusunda açıklanan Oturum Açma Bilgilerini Aktar DTS görevini kullanın: Günlük gönderimi rol değişikliğini ayarlama ve gerçekleştirme.

  • Birincil sunucudan syslogins tablonun dosyasını .bcp sağlamanız gerekir. Güncel olmayan bir dosya oturum açma bilgilerinin düzeltilememesine sp_resolve_logins neden olabileceğinden bu dosyanın güncel olması gerekir.

İkincil veritabanındaki oturum açma bilgilerini düzeltmeden önce sp_resolve_logins aşağıdaki üç koşulu karşılamanız gerekir:

  1. Tablonun dosyasındaki .bcpsyslogins oturum açma adı, birincil sunucudaki tablodaki syslogins adla eşleşmelidir.

  2. SID değeri, dosyanın oturum açma bilgileriyle .bcp ikincil veritabanındaki sysusers tablo arasında eşleşmelidir.

  3. İkincil veritabanındaki SID değeri, ikincil sunucudaki MASTER veritabanındaki syslogins tablodaki SID değerinden farklı olmalıdır.

Q303722'da açıklandığı gibi SQL Server oturum açma bilgileri oluşturursanız, tüm oturum açma işlemleri tabloda (ikincil sunucudaki MASTER veritabanında) ve sysusers tabloda (ikincil veritabanında) aynı SID değeriyle syslogins zaten sunulduğundan bu saklı yordamı çalıştırması gerekmez.

Sık sorulan sorular

  • Soru: Günlük gönderimi, güvenlikle ilgili değişiklikleri otomatik olarak ikincil sunucuya yayıyor mu?

    Cevap: Evet. Sistem tablolarındaki tüm değişiklikler günlüğe kaydedilen işlemler olduğundan, bunlar otomatik olarak ikincil sunucuya (veya sunuculara) yayılır.

  • Soru: İkincil sunucuda aynı SID'ye sahip iki oturum açabiliyor musunuz? Buna ihtiyacım var çünkü birden çok sunucudan birden çok bekleme veritabanını korumak için aynı SQL Server bilgisayarı kullanıyorum.

    Cevap: Hayır. SQL Server güvenlik modeli aynı SID ile iki oturum açma işlemine izin vermez. Birden çok sunucuyla günlük gönderimi kullanılırken SID'de çakışma varsa, bunu düzeltmenin tek yolu birincil sunucuda çakışan oturum açma bilgilerini bırakmak ve ardından ikincil sunucuda bulunmayan bir SID ile oluşturmaktır.