SQL Server Bitiş Noktası'nın güvenlik ayarlarını nasıl kontrol edebilirim?

SQL Server geliştirme ekibimiz için bir TEST ortamı oluşturma sürecindeyim.

Üretimde 3 SQL Server SQL01var, yansıtılan birkaç veritabanı içeriyor SQL02. SQL03"otomatik yük devretme ile yüksek güvenlik" veya senkron konfigürasyonda tanık olarak görev yapar.

VMWare P2V'yi her üç makineyi de ayrı bir donanıma sanallaştırmak için kullandım, makinelerin SID'lerini yeniden yapılandırdım ve üretim sunucularımızın IP adreslerini bu yeni makinelerden kararttık.

Başlangıçta prodüksiyon tanık makinesini karartmayı unutmuştum, bu yüzden TEST makinelerindeki veritabanları hala SQL03tanık olarak makineyi kullanıyordu . Soruna dikkat ederek, yeni sanallaştırılmış TEST tanığına işaret etmek için TEST'teki veritabanlarını yeniden yapılandırmaya karar verdim TEST03.

Veritabanını yeni tanığı kullanacak şekilde yeniden yapılandırmak için Birincil sunucuda aşağıdaki komutu girdim TEST01:

ALTER DATABASE [TestDB] SET WITNESS = 'TCP://TEST03.domain.inet:5022';

Yanıt beklenmedikti:

The ALTER DATABASE command could not be sent to the remote server instance
'TCP://TEST03.domain.inet:5022'.  The database mirroring configuration was
not changed.  Verify that the server is connected, and try again.

Yapılandırma üretim makinelerinde çalıştığından ve test makinelerinde hiçbir şekilde değiştirilmediğinden bu hata mesajında ​​çok şaşırdım.

Bu işe almak LOGINiçin test tanık bir oluşturmak gerekiyordu :

CREATE LOGIN [DOMAIN\SQLServiceAccount] FOR WINDOWS WITH DEFAULT_DATABASE [Master];

ve GRANTo CONNECTsöz konusu uç noktası üzerinde haklar:

GRANT CONNECT ON ENDPOINT::Mirroring TO [DOMAIN\SQLServiceAccount];

Daha sonra TEST ortamındaki yansıtılmış veritabanlarını yeni test tanığına başarıyla gösterebildim.

Üretim tanığı uç noktasını, onunla hangi güvenliğin ilişkili olduğunu görmek için nasıl inceleyebilirim?

İnceleyebileceğim bazı sistem kataloğu olması gerektiğini varsayıyorum, ancak Çevrimiçi Kitaplar, Uç Noktalar için belirli bir şeye sahip görünmüyor ve Bing iyi, Bingless ...

İlave bilgi:

SELECT ep.endpoint_id, p.class_desc, p.permission_name, ep.name, sp.name 
FROM sys.server_permissions p
    INNER JOIN sys.endpoints ep ON p.major_id = ep.endpoint_id
    INNER JOIN sys.server_principals sp ON p.grantee_principal_id = sp.principal_id
WHERE class = '105';

İadeler:

endpoint_id class_desc  permission_name endpoint_name   principal_name
2           ENDPOINT    CONNECT TSQL    Local Machine   public
3           ENDPOINT    CONNECT TSQL    Named Pipes     public
4           ENDPOINT    CONNECT TSQL    Default TCP     public
5           ENDPOINT    CONNECT TSQL    Default VIA     public

Ve:

SELECT name, endpoint_id, protocol_desc, type_desc, role_desc 
FROM sys.database_mirroring_endpoints;

İadeler:

name        endpoint_id  protocol_desc  type_desc           role_desc 
Mirroring   65536        TCP            DATABASE_MIRRORING  WITNESS

sys.server_permissionsYansıtma uç nokta nesnesi için giriş yok gibi görünüyor . Hayır major_idve hayır minor_id65536 ile eşleşir. Ayrıca, sistem veritabanlarının hiçbiri uç noktaya herhangi bir referans içermez.

Kayboldum.

Günün bir bölümünü SQL Server 2012'ye geçişe hazırlanmak için yansıtılmış veritabanlarını sunucudan sunucuya DEV ortamımızda taşımakla geçirdikten sonra , ENDPOINT güvenliğinin yalnızca hesap türüne göre belirlendiğini açıklayan bu MSDN belgesine rastladım . SQL Server altında çalışıyor. SQL Server bir etki alanı hesabı kullanıyorsa, o hesap otomatik olarak bitiş noktasına erişebilir. SQL Server, [Network Service] veya [Local System] vb. Gibi yerleşik bir hesap kullanıyorsa, uç noktanın bir güvenlik sertifikasıyla yapılandırılması gerekir ve yalnızca sertifikanın sahipleri uç noktaya erişebilir.

Belgedeki ilgili bölüm:

Bitiş Noktası Yansıtma Veritabanı için Kimlik Doğrulama Türünü Belirleme

Sunucu örneklerinizin SQL Server hizmet hesaplarının, uç noktalarınızı yansıtan veritabanınız için hangi kimlik doğrulama türünü kullanabileceğinizi aşağıdaki gibi belirlediğini anlamak önemlidir:

Her sunucu örneği bir etki alanı hizmeti hesabı altında çalışıyorsa, veritabanınızı uç noktaları yansıtan Windows Kimlik Doğrulaması'nı kullanabilirsiniz. Tüm sunucu örnekleri aynı etki alanı kullanıcı hesabı olarak çalışıyorsa, her iki ana veritabanında da doğru kullanıcı oturum açma bilgileri otomatik olarak bulunur. Bu, kullanılabilirlik veritabanları için güvenlik yapılandırmasını basitleştirir ve önerilir.

Bir kullanılabilirlik grubu için kullanılabilirlik kopyalarını barındıran herhangi bir sunucu örneği farklı hesaplar olarak çalışıyorsa, her bir hesabın oturum açma işlemi diğer sunucu örneğinde ana olarak oluşturulmalıdır. Ardından, bu sunucu örneğinin uç noktasını yansıtan veritabanına bağlanmak için bu girişe CONNECT izinleri verilmelidir.

Sunucu örnekleriniz Windows Kimlik Doğrulaması kullanıyorsa, Transact-SQL, PowerShell veya Yeni Kullanılabilirlik Grup Sihirbazı'nı kullanarak veritabanı yansıtma uç noktaları oluşturabilirsiniz.

Not:

Kullanılabilirlik çoğaltmasını barındıracak bir sunucu örneğinde uç nokta yansıtma veritabanı eksikse, Yeni Kullanılabilirlik Grup Sihirbazı otomatik olarak Windows Kimlik Doğrulaması kullanan bir uç yansıtma veritabanı oluşturabilir.

Yerel Sistem, Yerel Hizmet veya Ağ Hizmeti gibi bir yerleşik hesap altında çalışan bir sunucu örneği veya alan dışı hesap varsa, uç nokta kimlik doğrulaması için sertifika kullanmanız gerekir. Veritabanı yansıtma uç noktaları için sertifikalar kullanıyorsanız, sistem yöneticinizin her sunucu örneğini hem giden hem de gelen bağlantılarda sertifika kullanacak şekilde yapılandırması gerekir.

Sertifika kullanarak veritabanı yansıtma güvenliğini yapılandırmak için otomatik bir yöntem yoktur. CREATE ENDPOINT Transact-SQL deyimini veya New-SqlHadrEndpoint PowerShell cmdlet'ini kullanmanız gerekir. Daha fazla bilgi için, bkz. ENDPOINT OLUŞTURMA (Transact-sql).

Remus Rusanu (cevabında), yansıtma uç noktasında mevcut güvenliğin nasıl belirleneceğini doğru bir şekilde belirledi; de olduğu gibi:

SELECT ep.name, sp2.name AS Grantee, sp.name AS Grantor, p.permission_name, ep.state_desc
FROM sys.server_permissions p 
    INNER JOIN sys.endpoints ep ON p.major_id = ep.endpoint_id
    INNER JOIN sys.server_principals sp ON p.grantor_principal_id = sp.principal_id
    INNER JOIN sys.server_principals sp2 ON p.grantee_principal_id = sp2.principal_id
WHERE p.class_desc = 'ENDPOINT' AND ep.type_desc = 'DATABASE_MIRRORING'

Ancak benim durumumda SQL Server 2005'te orijinal yansıtma uç noktaları bu sorgunun sonuçlarında görünmüyor - bunun varsayılan güvenlik SQL Server altında çalıştığı hesaba (yukarıda açıklandığı gibi) CONNECT erişimine izin verdikleri için varsayıyorum.

Yani sorunun kanonik cevabı, bir ENDPOINT'e kimin CONNECT erişimi olduğunu nereden biliyorsunuz, yukarıdaki sorgunun toplamı ve SQL Server'ın kullandığı hesap, uç noktaya erişim ile yapılandırdığınız olası sertifikalarla birlikte .

Ben sadece üretimde bir veritabanı için bu ayarlanmış ve aynı şey merak ediyorum neden doğru eşleştiğinden emin olmak için yapılandırmayı başka bir yansıtma oturumu karşılaştırmak gerekiyordu.

sys.dm_db_mirroring_connectionssize istediğinizi sağlamalıdır. Aşağıdakileri içerir principal_name:

Bağlantı izinleri için doğrulanan oturum açma adı. Windows Kimlik Doğrulaması için bu değer uzak kullanıcı adıdır. Sertifika kimlik doğrulaması için bu değer sertifika sahibidir.

Eğer bu bilgileri yine de döndüreceğinden emin değilim ama duraklatılmış bir oturum ile çalışıyorsanız, sadece aktif bağlantıları olduğuna inanıyorum.

İçin Çevrimiçi Kitaplar belgelerine bakın sys.database_mirroring_endpoints

Sunucu nesnesi izinleri için olağan yere bakarsınız sys.server_permissions. Windows güvenliğinin dahil olduğu her durumda olduğu gibi, Windows grupları üyeliği nedeniyle işler daha karmaşıktır ve ayrıca izinler hiyerarşisini göz önünde bulundurmanız gerekir .