SQL Server'a erişmek için entegre güvenlik (SSPI) kullanmak web uygulamaları için daha iyi midir?

Web uygulamalarını (.net) bir üretim ortamına dağıtırken, entegre güvenlik kullanmak daha mı iyi, yoksa önemi var mı?

Bir bilgisayar korsanı web sunucusunu bozarsa, makineyi kolayca taklit edebildikleri için gerçekten önemli olmayacak.

Düşünceler?

SQL yetkisini kullanmak için yalnızca iki geçerli neden olduğunu söyleyebilirim:

1. Etki alanının dışından bağlanıyorsunuz, bu nedenle entegre kimlik doğrulaması.
2. Bir TPC-C karşılaştırması kullanıyorsunuz ve her döngü önemlidir. SQL yetkisi biraz daha hızlıdır.

Teklif ettiğiniz senaryo için (web sunucusu ana bilgisayarının güvenliği tamamen ihlal edilmiştir) hiçbir şey sizi koruyamaz. Bilgisayar korsanı, DB sunucusunda web sunucusunun yapabileceği en azından her şeyi yapabilir . Ve derinlemesine savunmanın size bu durumda kaybı en aza indirmeyi öğretebileceğini söyleyebilirim: ur web sunucunuz tarafından kullanılan hesabın DB haklarını kesinlikle gereken minimum değere ve daha fazla bir şeye düşürmeyin. İkinci olarak, web sunucusu ana bilgisayarının güvenliği ihlal edilmişse, web sunucusu hesabından daha yüksek ayrıcalıkları yükseltmek için kullanılamayacağından emin olun (örn. WWW ana bilgisayarında, DB'de WWW hesabından daha yüksek ayrıcalıklara sahip kimlik bilgilerini kullanan başka bir hizmet yoktur). Bunlar temel güvenlik ilkeleridir ve kullanılan kimlik doğrulama düzeniyle hiçbir ilgisi yoktur.

Sql kimlik doğrulaması ve windows kimlik doğrulaması, senaryoda net bir avantaj sağlamazken, dikkate alınması gereken başka sorunlar da vardır:

1. Merkezi politika uygulama: şifre kullanım süresi ve geçerlilik sonu, hesap fesih vb. Gibi şifre politikalarınızı ayarlamak için tek bir yeriniz vardır.
2. Kimliğe bürünme ve güven yetkisi üzerinde denetim. Bir sql yetkilendirmesi bir güven yetki zincirinde kullanıldığında, tüm bahisler gerçek 'yetki' olmadığı için artık kapalıdır ve bu nedenle artık politikalarınızın uyguladığı kısıtlamalar altında değildir
3. Denetim: sql auth, LSA'nız tarafından bile görülmez, bu nedenle tüm denetim altyapınız atlanır. SQL'in sql yetkilendirme olayları hakkında ürettiği kayıtları açıkça eklemeniz gerekir, ancak bu olaylar olay günlüğünde farklı kaynak, sağlayıcı ve şemaya sahip olduğundan elma ve portakalları karıştırır

Son bir not: TDS protokolü, sql kimlik doğrulama şifresini trafik üzerinde açık metin olarak gösterir, ancak bu genellikle trafiğin SSL şifrelemesini talep ederek hafifletilir.

Peki neden hala web.config dosyasında parolayı açık bir şekilde saklayan sql auth WWW ana bilgisayarlarını görüyorsunuz? Bunlar kötü geliştiriciler / yöneticiler, onlardan biri olma.

msdn.microsoft.com/en-us/library/aa378326(VS.85).aspx

technet.microsoft.com/en-us/library/ms189067.aspx

SSPI kullanmıyorsanız, kullanıcı adını ve şifreyi kaynak dosyalara kodluyorsunuz.

Kullanıcı adını ve şifreyi kaynak dosyalara kodluyorsanız, tüm çalışanlarınızın buna erişimi vardır.

Bu nispeten güvensizdir. Hoşnutsuz bir eski çalışan bilgiyi kötü amaçlı kullanabilir. Bir ziyaretçi kodu bir yerde ekranda görebilir. Veya kaynak kodu yanlışlıkla vahşi doğada çıkabilir.

SSPI'nin avantajı, parolanın hiçbir zaman net bir yerde saklanmamasıdır.

Şimdiye kadarki diğer cevaplar iyi, ama başka bir cevap vereceğim: yönetim.

Er ya da geç, muhtemelen birden fazla SQL Sunucusu ile sonuçlanacaksınız. Uygulamanızla birden çok SQL Sunucusu arasındaki SQL kimlik doğrulamasını yönetmek, özellikle güvenlik sorunlarıyla karşılaştığınızda biraz acı verici olur. Windows kimlik doğrulama parolasını bir kez değiştirirseniz, tüm sunucularınızda hemen değişir. SQL kimlik doğrulama şifrelerinizi döndürmeniz gerekiyorsa, daha acı vericidir - muhtemelen hiç yapmayacağınız noktaya kadar. Bu bir güvenlik riski.

Burada% 100 emin değilim, ama ana nokta SQL yetkisinin güvensiz olduğunu düşünüyorum, bu yüzden Windows yetkilendirmeyi kullanmak daha iyidir. Uygulamanızın kurulumuna bağlı olarak, Windows kimlik doğrulamasını kullanarak uygun kimlik bilgilerini makinede şifrelenmiş bir biçimde de saklayabilirsiniz. SQL yetkisi ile bunun gerçekten mümkün olduğunu düşünmüyorum. Bunu gizleyebilirsiniz, ama sonuçta net olmalıdır.

Ayrıca, bir bilgisayar korsanının sunucuya girebilmesi onun oyunun bittiği anlamına gelmez. Bilgisayar korsanı, ayrıcalıksız bir işlemin denetimini ele geçirebilir ancak sunucuda başka bir şey yapamaz. Bu nedenle her şeyi yönetici veya sistem olarak çalıştırmamak, bunun yerine minimum ayrıcalık hizmeti hesaplarını kullanmak önemlidir.

Yapılması gereken en iyi şey yapabileceklerini sınırlamak Eğer web sunucusuna girerlerse / ne zaman. Bu, yalnızca uygulamanın çalışması için gereken SQL haklarının verilmesi anlamına gelir. Uygulama DBO haklarını vermek çok daha kolay, ancak web sunucusuna başarılı bir saldırı durumunda DB'yi çok daha savunmasız hale getiriyor.

Tüm bunları, dahili özel ağdaki dahili bir web sunucusundan bahsettiğinizi varsayıyorum diyerek söyleyeceğim.

Makinenin kimliğine bürünerek başlayalım. Uygulama havuzu kimliği Ağ Hizmeti ise ve .NET uygulamasında kimliğe bürünme yoksa, evet, web uygulaması makinenin bilgisayar hesabını kullanarak arka uç SQL Server'a bağlanır. Bu, söz konusu makine hesabına erişim izni verdiğiniz anlamına gelir. Microsoft'un CRM'i bu şekilde çalışır.

Ancak, bir kimlik belirttiyseniz, söz konusu kullanıcı hesabının SQL Server'a erişmesi gerekir. Bir saldırgan web sunucusunu ele geçirirse kimlik hesabıyla etkin bir şekilde aynı erişime sahip olsa da, sorunun gerçeği, bir SQL Server oturum açma kullanmanın burada hiçbir şeyi değiştirmemesidir. Bir kez erişimim olduğunda, web uygulamasını istediğimi yapmak için değiştirebilirim ve arka uç SQL Server'da maksimum güvenlik izinleriniz olacak.

Şimdi neden SSPI kullanacağım. Her şeyden önce, SQL Server tabanlı bir oturum açma kullanmıyorsunuz. Bu, Active Directory'nin güvenlik için tek kaynak olduğu anlamına gelir. Bu, geçersiz erişimi belirlemek için normal denetim araçlarına sahip olduğunuz anlamına gelir. İkincisi, bunu gerektiren başka uygulamalar yoksa, SQL Server'ınızı yalnızca Windows kimlik doğrulama modunda bırakabileceğiniz anlamına gelir. Bu, SQL Server oturum açmaya izin verilmediği anlamına gelir. Bu, sa'ya yönelik tüm saldırıların başlamadan durdurulduğu anlamına gelir. Ve son olarak, iyileşmeyi kolaylaştırır. SQL Server tabanlı bir oturum açma kullanıyorsanız, oturumu SID ve şifreli parola ile ayıklamanız gerekir. Windows tabanlı bir kullanıcı hesabını "hizmet hesabı" olarak kullanıyorsanız, yeni bir SQL Server'a giriş yaptığınızda, giriş bilgilerini oluşturarak,

Soru hangisi "daha iyi"? Bu, cevaplayıcının bağlamına, değerlerine ve önceliklerine bağlı olduğu için cevaplanması zor.

Şahsen, SQL yetkisini seviyorum.

• AD, hizmet hesaplarını çalıştırmak ve desteklemek ve yönetmek için başka bir şeydir.
• AD'nin barındırma ortamınızda kullanılabilir olması gerekir.
• AD, buluta veya hibrit buluta geçmeyi zorlaştırır.
• AD, kuruluşunuzun başka bir bölümünde yöneticiler tarafından bulunmaması gereken gruplara hizmet hesapları eklemeyi kolaylaştırır.
• SSPI, yapılandırma dizesinde SQL ana makine adınızı şifrelemeniz gerektiği için bağlantı dizenizi şifreleme sorununu atlamıyor.
• SQL kimlik doğrulaması basit ve sadece metin yapılandırmasıdır, dağıtımı kolaydır.
• Uygulama Havuzu kimliklerini ayarlamak, her ortam için otomasyon komut dosyalarındaki kullanıcı adını ve parolayı otomatikleştirmek ve gizlemek için başka bir şeydir.
• İki bağlantı dizesi kullanmak, parolaları kullanmayı kolaylaştırır, böylece parolayı kesinti olmadan güncelleyebilirsiniz.

Son nokta: her bağlantı dizesini denemek için bağlantı yöneticisi sınıfınızı kodlarsınız, böylece yapılandırmada ilk parolayı değiştirebilir, değişikliği dışarı itebilirsiniz ve ikinci bağlantıya yük devredersiniz, sonra MSQL'de parolayı güncellersiniz ve birincisi tekrar kullanılacak. İkinci parolayı bir sonraki sefere hazır olan ilk parola ile aynı şekilde ayarlamak için son bir yapılandırma değişikliği gerekir.

Kullanıcılar veritabanını (SQL Server Management Studio gibi diğer istemci araçlarıyla) doğrudan manipüle etmeyeceklerse, genellikle uygulama için tek bir SQL girişi oluşturacağım ve ona gereken erişimi vereceğim. Bu noktada kullanıcı, web uygulaması arayüzünün izin verdiği şekilde yapabilecekleri konusunda kısıtlanır.