SSMS üzerinden belirli bir oturum açma için SQL Server'a erişimi reddetme, ancak izin verme .Net SqlClient Veri Sağlayıcısı

Geliştiricilerin UPDATEizinleri olmadığı , ancak uygulamalarla çalıştıkları ve bağlantı dizelerini gördükleri bir durumumuz var -> SQLLogin1UPDATE izinlerine sahip bazı SQL hesaplarından (örnek ) şifreleri biliyorlar . Operasyonlarımız şu anda mükemmel değil ve bazen üretim verilerinin değiştirilmesi gerekiyor (bunun için henüz GUI yok).

DBA ile iletişim kurmak ve ondan verileri değiştirmesini istemek yerine, Geliştirici (yanlış bir şekilde) SQL hesabını SQLLogin1(verileri değiştirme izni olan ) kullanır ve verileri değiştirmek için SQL Server Management Studio üzerinden bağlanır.

DBA, SQLLogin1Geliştirici'nin yeni bağlantı dizesini ve yeni parolayı görmesi için parolasını değiştiremez, çünkü kullanılan uygulama bağlantı dizesi SQLLogin1Geliştirici tarafından korunur.

Soru:

SQLLogin1SQL girişine erişimi reddetmenin bir yolu var mı , ancak yalnızca SSMS üzerinden bağlanıyorsa?

Aynı zamanda SQLLogin1üzerinde bağlanıyor .Net SqlClient Data Provider( program_nameiçinde sys.dm_exec_sessions), bu giriş için izin verilmelidir.

Bu şekilde, geliştiricinin SQLLogin1, kullanılan uygulama bağlanmaya devam ederken, SSMS üzerinden bağlantı kurmasına izin vermemek istiyoruz SQLLogin1.

Özel oturum açma doğrulamaları yapmak ve uygun gördüğünüzde reddetmek için bir sunucu oturum açma tetikleyicisi kullanabilirsiniz. SSMS kullanıyorsanız, bu tetikleyicinin "Sunucu Nesneleri" altında ve "Tetikleyiciler" içinde listelendiğini göreceksiniz.

Örneğin:

CREATE TRIGGER strRejectSSMSConnectionForSQLLogin1
ON ALL SERVER FOR LOGON
AS
BEGIN

    IF ORIGINAL_LOGIN() = N'SQLLogin1' AND PROGRAM_NAME() LIKE N'Microsoft SQL Server Management Studio%'
    BEGIN
        RAISERROR('Direct connection by SSMS refused.', 16, 1)
        ROLLBACK
    END

END

Tetiğin ROLLBACKiçi bağlantıyı reddeder (oturum açma olayında tetikleyiciye yapılan çağrıyı saran gizli bir işlem vardır).

Oturum açma tetikleyicilerini uygularken dikkatli olun, düzgün kodlanmazsa giriş yapabilmeniz gereken girişleri (kendiniz de dahil!) Reddedersiniz. Önce test / geliştirme ortamlarında test ettiğinizden emin olun.

Bu kodun oturum oluşturulmadan önce yürütüldüğünü unutmayın, bu nedenle oturum kimliğine (SPID) dayanan sistem görünümleri, tetikleyiciler geri alma veya yeterince yüksek bir hata olmadan sona erene kadar geçerli olarak denetlenen oturum açma bilgilerini içermeyecektir.

Ben cam herhangi bir kullanıcı tarafından Application Namedeğiştirilebilir değiştirilebilir çünkü sorun için güvenilir bir çözüm olduğunu düşünüyorum parameter.

İçinde nasıl değiştirileceği aşağıda açıklanmıştır SSMS:

Gelen Connect to Database Objectiletişim açık Seçenekler seçim Additional Connection Parametersve herhangi bir isim seçmek Application Nameböyle:

Şimdi sys.dm_exec_sessionsDMV ve Program_name (), Application Nameparametre parametresinde bağlantı dizenize ne ilettiğinizi gösterecektir :

Diğer yanıtlarda ayrıntılı olarak açıklandığı gibi belirli bir istemciyi kesemezsiniz.

Çözüm, geliştirici hesaplarından üretim sistemlerine erişim ayrıcalıklarını kaldırmaktır.

Herhangi bir değişiklik betiklenmeli ve bir dba betiği çalıştıracaktır.

Dağıtım bir sistem yöneticisi tarafından gerçekleştirilir; devs, uygun ayrıcalıklara sahip birine verdikleri bir paket üretir ve devs, üretim sistemlerinde kullanılan yapılandırmaları asla görmez.

Hata ayıklama, tercih edilen bir çözüm olarak bir hazırlama ortamında üretim verilerinin bir kopyası veya gerekirse sınırlı ayrıcalıklara sahip geçici bir hesapla duruma göre düzenlenir.

1. İdeal anlamda, bu bir süreç / politika / yönetim meselesidir. Birisi şifreyi bilse bile, DBA'dan başka birisinin Üretim'e bağlanması şirket politikasına aykırı olsa bile (Eh, bir Yayın Mühendisliği ekibiniz ve / veya sistem yöneticileriniz vb. Olabilir) ve kuralları ihlal etmenin cezaları vardır, o zaman bu yeterli olmalıdır (bu tür kuralların uygulandığı varsayılarak).

2. Belirli bir uygulamanın bağlanmasını engellemeye çalışmak imkansızdır. Gibi gösterdi sepupic , bu "programı adı" değiştirmek oldukça kolaydır. Ancak geliştirici bunu anlayamasa bile, SQL Server'a bağlanabilen birçok başka program var. Çoğu insan SQLCMD.exe ve hatta kullanımdan kaldırılmış OSQL.exe erişimine sahip olacaktır . Geliştirici Visual Studio içinden bağlanabilir ve ".Net SqlClient Data Provider" aracılığıyla bağlanmak için kendi uygulamalarını bile oluşturabilirler. Ve şimdi Azure Data Studio'muz bile var. Çok fazla.

3. Yine de, diğer yönden yaklaşırsak yine de mümkün olabilir: X uygulamasının bağlanmasını önlemek yerine, yalnızca Y uygulamasının bağlanmasına izin vermeye ne dersiniz? Tabii, biz tekrar "program adı" içine almak ve hatta "hostname" sahte olabilir, ama istemcinin IP adresi (en azından bağlantı dizesi anahtar kelimeler üzerinden) sahte olamaz eminim. Uygulama sunucularının IP Adreslerini biliyorsunuz veya sys.dm_exec_connectionsDMV'den ( client_net_addressalanda) kolayca bulabilirsiniz .

   EzLo tarafından önerilen Oturum Açma Tetikleyicisi ile başlayarak , bağlantının geçerli olup olmadığını belirleyen mantığı değiştirebiliriz:

   IF (ORIGINAL_LOGIN() = N'SQLLogin1'
       AND (
                CONVERT(VARCHAR(10), CONNECTIONPROPERTY('net_transport')) <> 'TCP'
             OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address')) <> '10.10.10.10'
    -- uncomment below (and comment-out line above) if app uses multiple IP addresses
    --       OR CONVERT(VARCHAR(10), CONNECTIONPROPERTY('client_net_address'))
    --                   NOT IN ( '10.10.10.10', '10.10.10.11', ...)
           ))
   BEGIN
       RAISERROR('Non-application connection refused.', 16, 1);
       ROLLBACK;
   END;
   

   Şimdiki tek yol, Üretim makinesine oturum açmak veya iş istasyonlarının uygulama sunucusunun IP'sini taklit etmek olabilir. İnşallah devs, Üretim oturum açmak için herhangi bir erişimi yok. Ve ağdaki mevcut bir IP'yi taklit etmek Üretimi olumsuz etkileyebilecek sorunlara neden olur, bu yüzden bunu denemeyecekler, değil mi? Sağ?

Daha önce bir geliştiriciyle bu sorunu yaşayan bir şirkette çalıştım. İşten çıkarıldı, ancak Giriş Tetikleyicisi aracılığıyla LoginName ve AllowMachine (Uygulama Sunucusu) içeren bir tablo da uyguladık. Bu bizim sorunlarımızı çözdü. Ya da belki de ateşten kaynaklanıyordu.