Neden herkesin sa girişini kullanmasına izin vermek kötü bir uygulama?

Microsoft bile , SQL Server kimlik doğrulama modunun kullanılmasını önermez , ancak uygulamalarımız gerektirir.

Kullanıcıların sadoğrudan Windows Kimlik Doğrulaması'nı kullanarak ve bu hesaplara (veya hesap gruplarına) sysadmin ayrıcalıklarına izin vermek yerine , giriş bilgilerini doğrudan kullanmasına izin vermemenin en iyi yöntem olduğunu okudum .

• Bu aslında aynı şey değil mi? Avantajlar / dezavantajlar nelerdir?
• En iyi uygulama, SQL Server örneklerimin güvenliğini nasıl artırır?
• Bu yalnızca üretim örnekleri için mi yoksa iç gelişim örnekleri için de geçerli mi?

Burada birkaç farklı sorunuz var, bu yüzden tek tek göndereceğim:

"Kullanıcıların doğrudan Windows Kimlik Doğrulaması'nı kullanarak sa girişini kullanmalarına izin vermemek için en iyi yöntem olduğunu okudum"

Burada iki şeyi karıştırıyorsunuz: SA kavramı ve SQL kimlik doğrulaması ve Windows kimlik doğrulaması kavramı.

SQL kimlik doğrulaması, her SQL Server'da depolanan kullanıcı adlarının ve şifrelerin bir listesidir. SQL'de depolanmış olması ilk sorun. Bir oturum açma şifresini değiştirmeniz gerekirse, her sunucuda değiştirmeniz (veya farklı sunucularda farklı şifreler bulundurmanız) gerekir. Windows kimlik doğrulaması ile girişleri merkezi olarak devre dışı bırakabilir, şifreleri değiştirebilir, politikaları belirleyebilir vb.

SQL kimlik doğrulaması kullanmayı seçerseniz, SA yalnızca bir SQL kimlik doğrulama girişidir. Varsayılan yönetici kullanıcı adı, tıpkı Yönetici'nin Windows kimlik doğrulamasında olduğu gibi. Bu durumda yerel süper güçlere sahip, ancak tüm durumlarda küresel süper güçlere sahip değil.

"... ve bu hesaplara (veya hesap gruplarına) sysadmin ayrıcalıklarına izin vermek."

Hangi kimlik doğrulama yöntemini seçerseniz seçin, ideal olarak en az ayrıcalık ilkesini takip etmek istersiniz: insanlara işlerini yapmalarını sağlamak için ihtiyaç duydukları asgari hakları verir ve daha fazlasını yapmazsınız.

Onları sadece girişler olarak düşünmeyin - onlar sizi kovabilecek insanlardır. Veritabanını düşürürler veya yanlışlıkla yedekleme işlerinizi devre dışı bırakırlarsa, kovulmayacaklar çünkü varsayılan olarak, SQL kimin yaptığını izlemiyor. Kovulacak olan sensin, çünkü olacak ve hangi kişinin yaptığını söyleyemeyeceksiniz.

"En iyi uygulama, SQL Server örneklerimin güvenliğini nasıl artırıyor?"

İki şey yapmak istiyorsun:

1. İnsanların sunucuyu kırmasını önleme
2. Sunucuyu kırdıklarında tam olarak kimin yaptığını tanımlayabilmek

Birincisi, en az ayrıcalık ilkesiyle gerçekleştirilir: insanlara yalnızca ihtiyaç duydukları izinleri vermek ve daha fazlasını yapmak.

İkincisi, herkese kendi giriş bilgilerini vererek, paylaşılan girişlere izin vermemek (herkesin aynı kullanıcı adını / şifreyi kullanmasına izin vermek gibi) ve ideal olarak girişleri denetleyerek başarılır. Muhtemelen bu son kısmı hemen yapmayacaksın, çünkü biraz acı verici, ama önce parçaları yerlerine koyalım, böylece birileri veritabanını bıraktıktan sonra daha sonra denetim ekleyebilirsin ve patronun nedenini bilmek istiyor.

Ne düşündüğünü biliyorum: "Ama uygulamaları kodluyoruz ve uygulamanın bir giriş yapması gerekiyor." Evet, uygulamaya kendi girişini verin ve geliştiricilerin bu şifreyi bilmesi gerekir, ancak bu giriş, aklı başında hiç kimsenin kullanmak istemediği izinlerden arındırılmalıdır. Örneğin, db_datareader ve db_datawriter rollerinde yalnız olması gerekebilir, başka bir şey yok. Bu şekilde veri ekleyebilir, güncelleyebilir, silebilir ve seçebilir, ancak şemaları değiştirebilir, dizinler ekleyemez, saklı yordamları değiştirebilir vb.

“Bu sadece üretim örnekleri için mi yoksa iç gelişim örnekleri için de geçerli mi?”

Sanırım bu, geliştirme durumlarına da uygulanacağını düşünüyorum çünkü genellikle insanların bir şeyleri kırmasından endişe ediyorum. İnsanlar sadece geliştirme aşamasında sunucuları kırmayı severler. Ve tabii ki, üretime geçirilecek değişikliklerin listesini bir araya getirme zamanı geldiğinde, uygulamanın belirli bir dizinin gerçekten hayati olup olmadığını ya da bazı bağların Veri Tabanı Ayarlama Danışmanını yönetip düzenlemediğini ve tüm değişiklikleri uyguladığını söylemeliyim. . Uygun izinler bu acıyı azaltmaya yardımcı olur.

Aslında bu teknik incelemeyi okuduysanız: SQL Server Ödev Ayrıntısını

Size NO ONE hesaplarında sysadmin yetkilerini kullanması gerektiğini söyleyecektir . Günlük erişim hesabınıza, açık sysadmin hakları değil, minimum erişim izni verilmelidir. Onlara göre KONTROL SUNUCUSU aslında sysadmin'in ne olduğuna yakındır ve daha sonra ihtiyaç duymadıkları yerlerde DENY / REVOKE erişimine hala izin verir. Herhangi bir BT uyumluluk standardına uymanız gerekiyorsa, sysadmin haklarının herkese izin verilmesi bir sorun haline gelir. Standartların çoğu, sysadmin rolünün asgari kullanımını gerektirir.

İşletim sistemindeki yerleşik yönetici hesabında yaptığınız gibi "sa" hesabını devre dışı bırakır ve yeniden adlandırırım. Sadece acil durumlarda kullanılmalıdır.

Geliştiricilere genellikle geliştirme ortamlarına tam erişim sağlanır. O zaman programları prodüksiyon öncesi örneğe taşındığında, girişleri minimum ya da hiç olmalı; tıpkı üretimde olduğu gibi. Bu mükemmel bir dünya. Bununla birlikte, siz bu konuda değilseniz ve geliştiricilerinizin ihtiyaç duyduklarından daha yüksek bir imtiyazı varsa, hesaplarını kontrol altına alırım. Her şeyi ve bir ölçüde yaptıklarını yakalardım. Dolayısıyla, üretim sunucunuzdayken bir şeyler ters gittiğinde, geri dönüp tam olarak ne yaptığını öğrenebilirsiniz.

Dış düzenleyici kontrollere veya standartlara (SOX, PCI vb.) Tabi ise, o zaman

• bir denetim başarısız olur
• aylık PCI çeklerinde başarısız oluyor

Geliştiriciler, yalnızca geliştirme amacıyla bir ağ SQL Server'da db_owner'a sahip olmalıdır.

SQL Sunucularınızın tümü ağ üzerinde standart bir yapıya sahipse (yani aynı hizmet hesabı), o zaman bir tanesine hepsinin haklarını verir.

Hizmet hesabı yerel yönetici ise, geliştiricileriniz de sunucular üzerinde tam denetime sahiptir.

Başka taraf yok.

sa = sysadmin

Sa ile giriş yapmak, kullanıcıya aşağıdakileri yapma yetkisi verir: - bırak ve veritabanları oluştur - veritabanındaki nesneleri değiştir - bırak ve giriş yap - şifreleri değiştir - tüm verileri sil

Windows hesabı sysadmin ayrıcalıklarına sahip olmak aynı şeyi gerçekleştirir.

Liste devam ediyor, ancak bu yönetici olmayan bir sa kullanmasına izin vermeyin.

Uygulamaların çalışması için gerekli olan minimum yetkilere sahip bir pencere veya SQL hesabı oluşturmanız gerekir. (örneğin giriş, saklı yordamlar ve görünümler erişim)

En iyi uygulama, güçlü bir parola koymak ve unutmaktır.

Şu anda aklımda iki seçeneğim var, neden birinin zayıf bir SA hesabına sahip olmaması gerektiğine dair. SA için zayıf / boş bir şifreniz varsa, kötü bir kişi (bunu 'dost meslektaşınıza' çevirin):

• xp_cmdshell sistem prosedürünü etkinleştirin ve Sql Server hizmet hesabının ayrıcalıklarını kullanarak yerel kutunuza zarar verin (dosya oluşturun / kaldırın ..). SA için düşük güvenlik düzeyine sahip olmak aslında örnek ayarlardan pek bahsetmiyor, ancak hizmet kullanıcısının kötü uygulamaları izleyebileceği anlamına gelebilir (yönetici olmak gibi :-));

• örneğinizde postayı etkinleştirin ve küçük bir spam eğlenceli betiği hızlı ileri sarın (bu, muhtemelen internet sağlayıcınızla veya iş arkadaşlarınızla sorun yaşamanıza neden olur.);

Veritabanlarını, girişleri, vb.leri bırakabileceği açık gerçeklerine dikkat çekmeyeceğim.

• Bu aslında aynı şey değil mi? Avantajlar / dezavantajlar nelerdir?

• Mutlaka gerekli değil: örneğin - dizüstü bilgisayarınızdan gelen SQL Server örneğinde, Windows kimlik doğrulaması ile SQL kimlik doğrulaması arasındaki fark teorik olarak, harici bir saldırganın yalnızca bir SQL hesabı kullanabileceği anlamına gelir, çünkü Windows kimlik doğrulaması kendi etki alanının dışında kullanılamaz hesap. Bir kullanıcı, kahve içtiğiniz alışveriş merkezindeki komşu dizüstü bilgisayarları tarayabilir ve bir SQL örneğinin kurulu olduğunu ve başladığını görebilir ve ücretsiz olarak eğlenmeyi deneyebilir. Sık sık olabileceği değil ... ama bir olasılık :-).

• En iyi uygulama, SQL Server örneklerimin güvenliğini nasıl artırır?

• Bu dünyadaki en iyi uygulamaların her biri işini yaptığı gibi ... olası bir dezavantaj olasılığını azaltmaktadır (örneğin: en iyi fiziksel aktivite yapmanın yolu benim gibi olma olasılığını azaltacaktır).

• Bu yalnızca üretim örnekleri için mi yoksa iç gelişim örnekleri için de geçerli mi?

• En azından üretimde güvenlik için en iyi uygulamaları (ortamınızın ihtiyaçlarına göre test edilmiş ve değiştirilmiş) uygulamanızı önerdiğimi varsayalım. Ancak geliştirme aşamasında, geliştirme verilerini de değiştirmek zorunda olduğunun güçlü bir göstergesi olduğundan, üretim verilerini de (hassas .. vb.) Kullanırsanız.

Son sorunuza değinmek için, tüm geliştirme veritabanlarımızda SA hesaplarını kullanıyoruz ("sa" şifresiyle!)

Ancak, verileri saklamadığımızı ve verileri üretmediğimizi not etmek önemlidir. Veritabanlarımız yalnızca bir C / C ++ uygulaması için bir veri deposunda kullanılmaktadır. Bu geliştirme veritabanları yalnızca test verileri içerir ve sık sık oluşturulur, çıkarılır, değiştirilir, vb.

Ayrıca, kritik olduğu kadar, tüm geliştirme veritabanları geliştirme makinelerine kurulur. (Her geliştirici için bir kopya, en azından!) Birisi bütün bir kurulumu tamamen çökertmişse, yalnızca kendilerini ve başka kimseyi mahvetmedi.

Veritabanınızın, tablolarınızın ve verilerinizin gerçekten tutarlı ve güvenli olduğundan emin olmak istediğiniz bir ortama gelince, iyi ve sağlam bir SA şifresi istiyorsunuz. Bunu zayıf bırakırsanız, herkes ve herkes verilerinize tam olarak erişebilir ve veritabanınızı tamamen imha edebilir.

Tamamen test verileri içeren veritabanının kendi kopyalarına sahip bir grup geliştirici için, hala güçlü bir SA hesabını sürdürmek için sağlam bir argüman bulamadım.

Sağlanan herhangi bir varsayılan SQL Server sistem güvenliği parametresi değiştirilmelidir. Kimlik doğrulama için karma modun kullanılmaması (hem Windows hem de SQL Server kimlik doğrulamasını etkinleştirir) önerilir. Bunun yerine, yalnızca Windows kimlik doğrulamasına geçin - bu, Windows şifre politikasını uygular - şifre uzunluğunu, ömrünü ve geçmişi kontrol eder. SQL parola kimlik doğrulamasından farklı kılan Windows parola ilkesinin özelliği oturum açma kilitlemesidir - bir dizi başarılı başarısız oturum açma girişiminin ardından oturum açma kilitlenir ve daha fazla kullanım için kullanılamaz hale gelir

Öte yandan, SQL Server kimlik doğrulaması kaba kuvvet saldırı girişimlerini saptamak için herhangi bir yöntem sağlamaz ve daha da kötüsü, SQL Server çok sayıda hızlı oturum açma girişimi için bile optimize edilmiştir. Bu nedenle, SQL Server kimlik doğrulaması belirli bir SQL Server sisteminde şartsa, SA girişini devre dışı bırakmanız önemle tavsiye edilir.