Soru SQL Server Güvenlik Crackdown


2 yıldır bir şehir için SQL Server DBA olarak çalışıyorum.

Mevcut bir DBA'yı desteklemek için getirildim, bu yüzden yavaş yavaş kurum içinde güvenilirlik kazanmaya çalışarak bir süre çalıştım ve bir süredir çalışıyorum. En zor ve en önemli sorunla başa çıkmanın zamanı geldi: güvenlik.

Ana sunucumuz, üzerinde SQL 2005 bulunan bir yük devretme kümesidir. 166 veri tabanına sahiptir. Çoğu uygulama için uygulama havuzu ile 550 ya da öylesine bağlantı sağlar, böylece binlerce kullanıcıyı kolayca destekler. Ayrıca, adil bir trafik alan kamuya açık bir web sitesine de hizmet veriyoruz. Satıcı uygulamaları, şirket içi uygulamalar, erişim arka uçları - birkaç kritik uygulama ile oldukça çeşitli.

Birçok geliştiricinin üretim erişimi var. Değişiklikler RFC sürecinin dışında yapılır ve geliştiriciler tarafından hangi verilerin değiştirildiği hakkında hiçbir fikrimiz yoktur. Ayrıca, sistem uygulamaları sırasında üretim yapmaktan da keyif alıyorlar.

Birçok uygulama ile, herhangi bir aklı başında DBA sunucuyu kilitle.

Geliştiricilerin bir takımını geniş açık güvenlikten daha kısıtlayıcı bir ortama nasıl geçireceksiniz?

Sınırlı bir süre için veritabanlarına erişmelerini sağlayacak bir acil durum talep sistemi üzerinde çalışıyorum. Bu bize erişim ve ddl değişikliklerini denetler. Umarım bu kullanılmayacaktır - bir sayfaya cevap vermediğimiz anlamına gelir. Ekranda HTTP, şifrelenmiş webconfig, login / pwd (e-posta değil) kullanacak, 12 saatte 3'e çekmeyi talep edecek. Bir giriş yapıldığında da biz de çağrı yapılacaktır.

Bu tür bir sistem hakkında herhangi bir uyarı var mı?

Görebildiğim en büyük risk, bir kullanıcının ntlogin'i tehlikeye atmış olsaydı, onların veritabanları olurdu. Şu anda bu güvenlik açığına sahibiz, çünkü her zaman erişime sahipler, ancak bunun olup olmadığını asla bilemezlerdi.


düzenlemeler: Geliştirme ve evreleme, 8 çekirdek ve 8GB belleğe sahip sağlam sistemlerdir. Geliştiricilerin, db'leri masif değilse ve hassas bilgiler içermiyorsa, geliştiricilerin çalışabileceği stg kopyalama mekanizmasına prd uygulanması planlanıyor.

Yönetim destekleyici. Acil durumlarda onlara erişimlerini garanti edebilirsek, onların en büyük endişesi halledilir. Diğer problem, uygulama sırasında üretime erişime sahip olabilir - vermemeyi tercih ederim. İlk aşamaya geçme hamlesini uygulayabiliriz ve DBA'ların prd.


7
2017-09-22 22:44


Menşei


İlk sorum şu: Gücüne sahip olanlardan nimetiniz var mı? Muhtemelen bildiğiniz gibi, insanlar bir şeye alıştıktan sonra, onu götürmek çok zor, şimdi ölçeği rahatlık / rahatlıktan güvenlik alanlarına aklı başında bir pozisyona atmaya çalışıyorsunuz. Eğer geliştiriciler üzülüyorlarsa (ki kesinlikle öyle olacaklar) ve şikayet ederseniz, yöneticiniz ve müdürü sizi destekleyecek mi? Eğer değilse, ilk denemem yöneticimi ve yöneticilerini tam olarak içinde bulunduğumuz durumun ne kadar kötü olduğunu göstermek ve var olan tüm görünmez ama çok gerçek risklerden haberdar etmektir. - Xerxes
Acil durum sisteminizi uygulayacaksanız, sadece kimlik bilgileri kaybına maruz kalmamanız için ikinci bir kimlik doğrulama türü eklemeye bakın. Erişim portalınıza iki faktörlü kimlik doğrulaması yapmak zor olmamalı ve herhangi bir masraf kolayca haklı gösterilmemelidir. - Chris W


Cevaplar:


Aynı şeyle şirketimde çalışıyorum. Aslında insanların çoğunun düşündüğümden daha açık olduğunu fark ettim, ama birkaç şey önemli oldu:

  • Onlara birincil amacın kazaları önlemek olduğunu hatırlatırız. Kazalar herkesin ilişki kurabileceği bir şeydir. Hemen hemen hiç kimse hacklenmeyeceğini düşünüyor ve iç hackerlar hakkında konuşarak onları hemen savunmaya koyuyor ("Bana güvenmiyor musun?").
  • Bir bloğa girdiklerinde isteklere hızlıca yanıt verin.
  • Onlarla çalışmak için istekli ol. Başlangıçta kilitlendiğim bazı şeylerin işlerini yapmaları için gerekli olduğunu ve geri açıldıklarında sorunlara neden olmayacağını gördük.
  • Tutarlı olun. Bu politikaları evrensel olarak uygulamanız gerekiyor. Mümkün olduğunda, bunları kendinize de uygulayın.

Bunu daha az yıkıcı hale getirmek için daha küçük artışlarla yapmaya çalışıyorum. Örneğin:

  • Tüm yeni veritabanlarının artık başlangıçtan itibaren kısıtlı izinleri var. Hiç sahip olmadığın şeyi kaçırmıyorsun.
  • Sysadmin ve diğer sunucu düzeyinde hakları kaldırarak, şu anda sahip olmaları durumunda başlayın. Çoğu kişi, sunucuyu yeniden yapılandırmaya ihtiyaç duymadıklarını kabul eder ve birçok güvenlik açığını ortadan kaldırır. Bununla yaşayabileceklerini gördükten sonra, aşamalı olarak daha sıkı bir sıkma için aşama oluşturuyor.
  • Bir seferde bir uygulamanın veritabanlarını sıkın. Bu, sizin için daha kolay yönetilebilir hale getirir, artı zamanda ihtiyaç duydukları hakların öğrenilmesini sağlar, böylece gelecekteki sıkışma daha sorunsuz ilerler.

İyi şanslar!


1
2017-09-23 16:36



Birkaç hafta önce konuştuğumuzda ilk noktanıza çok açıklardı - bir geliştirici olarak, üretim verilerine yanlışlıkla zarar vermenin hiçbir yolu olmadığını bilmek biraz rahat olurdu. Bu sene bazı kritik sistemlere sahip iki tane kaza geçirdik, bu yüzden bu karışıklığı temizleyen kişi olduğum için onu uyardı.


Gerçekleştirilen şema değişikliklerini almak için bir DDL tetikleyicisi yerleştirerek başlayın. Sadece her DDL komutunu, kimin ve ne zaman aradığına bakarak kaydederiz.

Göründüğü kadar kötü şeyler olmadığını fark edebilirsiniz. Çoğu değişikliği kimin dışarıda bıraktığını araştırın ve onları gemiye alın. Bundan sonra, işleri daha iyi bir şekilde bağlayabilmelisiniz.

Ayrıca, - uygun uygulamalarınız olmayan uygulamalardan nelerin alındığını öğrenmek için bir iz bırakınız. İzleme içindeki ApplicationName ve / veya HostName alanlarına bakın. Bu, anlık sorgular için bir alan elde etmenize yardımcı olacaktır. O zaman verileri sık sık kesmek için kimlerin fırlatılacağını bulmanız gerekir.

Her zaman önce bu tür durumları izlemeyle başlarım. Yakında kilitleyin, ancak sorunun ne kadar büyük olduğunu görmek için şimdi izlemeye başlayın.


3
2017-09-23 00:37



Pragmatik bir yaklaşım için +1 - Nick Kavadias
DDL'nin yerinde var. İzlemeyle ilgili olarak - sunucuyu zorlamayan makul miktarda veriye nasıl filtrelersiniz? Tüm aktiviteleri izleyemeyiz. Uygulama = SQL Management Studio?
Izleme oluşturduğunuzda (Profiler kullanın ve bunun için bir komut dosyası oluşturduğunuzda), bir Sütun filtresi yerleştirin. - Rob Farley


Bu ciddi bir girişim. Bu insanlar muhtemelen kendi yollarında çok belirgindirler ve değiştiklerini elde etmek için üstlerinden çok fazla destek alacaktır. Zaten bir test ortamı var mı? Yaptıklarını farz ediyorum ama yapmazlarsa birinci adım olmalı. Ayrıca, enfiye olup olmadığından emin olun. Eğer yaşlı ve yavaşsa, onu kullanmaya zorlanmaktan şikayet ederler. Onları diplomatik yollardan çıkartabilmek için onlara test gibi diğer alanlarda bir kemik atmaya hazır olmalısınız.


1
2017-09-22 22:53





Baş geliştiricilerle tanışın ve üretim erişimine sahip olma nedenlerini öğrenin. Muhtemelen çoğunu zaten biliyorsunuzdur. Ardından nedenlerini kaldırın / giderin. Sunuculara tam üretim erişimi olan bir geliştirici ekibinden biriyim ve bunun olmaması gerektiğini biliyorum. Şu ana kadar meslektaşlarımdan üç tanesini, SQL ya da kayıtsızlık nedeniyle ciddi bir bozulmaya neden gördüm. "değişiklikleri hemen uygulamaya koymalıyız" - "bir komut dosyası yaz, ben incelerim ve tamamsa onu çalıştırırım." "Canlı verilere ihtiyacımız var" - "Cidden mi? Yoksa gecenin yedeğini mi alacak?" "Bunu test etmem gerekiyor, işe yarayıp yaramadığına bak" - "Yeni sanal test sunucunuza merhaba deyin."

Şimdiye kadar üç kaza geçirdik ve eminim ki, güvenlik kilitlememiz hala bir şekilde kapalı.


1
2017-09-23 00:02



Toplantıyı büyük geliştiricilerle yaptık - isyan yoktu.


Bir şehir için çalıştığınızı söylüyorsunuz, ama sizden bir devlet çalışanı, bir sözleşme şirketi veya hatta bulunduğunuz ülkede olduğunuzdan emin olamam.

Bu değişikliği yapmak istiyorsanız (ve gerçekten, geliştiriciler asla herhangi canlı ortama erişim [Ben bir üst geliştirici BTW]) o zaman amatör geliştiricilerinizi almak için yönetimden destek almanız gerekiyor (yani üretim DB'si üretim kullanımı içindir, sizin yarı-götünüzün neden olduğunu anlayabilmeniz için değil) kod, "ne olacağını gör" için rastgele sorgular çalıştırarak çalışmaz.

Bunlardan birinin kuruluşunuz için geçerli olup olmadığını kontrol etmenizi şiddetle tavsiye ederim:

SOX (ABD'de halka açık şirketlere uygulanan Sarbanes-Oxley Yasası)
Bill 198 (Ontario Eyaleti ve dolaylı olarak CSA kuralları ile Kanada'nın geri kalanı)
CLERP-9 (Avustralya)
J-SOX (Japonya)

Bunların hepsi aynı şeyi yapıyor, hissedarlara bildirilen mali kaynakların mümkün olduğunca sahtecilikten uzak olmasını sağlıyor. Bir unsur sorumlulukların ayrılmasıdır - BT'de bu, geliştiricilerin asla üretim verilerine okuma veya yazma işlemlerine doğrudan erişim. Tüm eylemler, sunucu yöneticilerinden geçmelidir. yazılı Denetim amaçlı tutulması gereken imzalı istekler (imtiyaz formları).

Her durumda yönetim çok hızlı bir şekilde yanınıza gelecek - SOX altında yönetim Uygun "kontroller" mevcut değilse, sorumlu (hapis cezası!)


1
2017-09-23 17:40



Biz bir ABD belediye yönetimindeyiz, bu yüzden SOX tarafından yönetilmiyor. Bazı veriler HIPAA ve PCI tarafından karşılanmaktadır - ancak güvenlik ve dış değerlendirmelere göre mevcut durumumuz kabul edilebilir. >> yarı-gerçel kodunuzun neden "göründüğünü gör" için rasgele sorgular yürüterek çalışmadığını anlamanız için değil, üretim okumasına bile sahip olmamasını önerdiğimiz zaman flabbergrasyon yapıyorlardı. Birçoğu büyük ölçekli ortamlarda çalışmadı.


En büyük endişeniz uygunsuz hesaplarla giriş yapan uygulamalardır. dba. Kapıları çarpmadan önce bağlantılarınız üzerinde bir denetim yapmanız gerekecektir.

Üreticilerin üretim SQL erişimi kapalı olması çok zordur, bu yüzden erişimi olabildiğince ani ve keskin hale getirin. Yönetim desteğine sahipseniz, diplomasi endişelenecek en önemli şey değildir. Güvenlik ve güvenilirlik tüm kozları.

İyi olmanız gerekiyorsa, tüm geliştiricileri oturun ve onlara ne olacağını ve acil bir durumda hangi süreçlerin olacağını söyleyin. Üretim verilerinin düzenli olarak yedeklenmesini sağlayın. Güvenliğindeki verilerle oynayabilirler.

Acil bir durum varsa, yedeklemeyi her zaman aşamalandırmaya geri yükleyebilir, ihtiyaç duydukları değişiklikleri betimleyebilir, test edebilir ve komut dosyasını gönderebilirler.

Veritabanına üretim erişimi olan bir geliştiriciyim. Güncelleştirme istatistiğini çalıştırmak ve nerede yan tümce sooo kolayca unutma.

Eğer o kadar sert olmak istemiyorsan, Sadece oku Veritabanının hakları iyi bir geçici adım olmalıdır.


1
2017-09-23 04:37



Senden başladığına katılıyorum. Bu sizin birincil endişeniz olmalı, uygulama kullanıcılarının hesaplarının mümkün olan en doğru ve en kısıtlayıcı izinlere sahip olması. - Chris Marisic


Bir geliştirici olarak oraya atmak zorundayım.

Senden nefret ediyorum.

DBA'ların bizi iş yapmaktan alıkoymak istemeleri aptalca. Sistemin üzerinden serbest dolaştık. Yani hesabımı kilitledin mi? Yapmam gereken tek şey, görsel bağlantı hata ayıklama kodumdaki üretim bağlantı dizgisini bırakıp gidiyorum ve uygulamanın yapabileceği her şeyi kontrol edebiliyorum.

Geliştiricilerin üretimden çıkarılmasının db herhangi bir güvenlik sağladığı fikri, bir aptal inancıdır.

Şimdi bir geliştirici olarak, tavsiye edeceğim şey, bunları db'den tamamen zorlamaya çalışmak yerine (özellikle dağıtımlar sırasında işin maliyeti için) büyük güncellemeler / silmeler / ekler üreten tüm betiklere gereksinim duymak için bir politika benimsemektir. db ekibi tarafından gözden geçirilmesi gerekmektedir.

Rob'un dediği gibi, tüm DDL'nin db'ye girmesini ve daha sonra geliştiricilerin bu kuralı ihlal etmelerini, bunu yönetime rapor etmelerini ve durumlarla başa çıkmalarını sağlayın.

Db'yi geliştiricilerden korumak için ihtiyacınız olan tek şey, 100 sayfanın yerine tüm tabloyu güncelleyen kötü yazılmış bir birleşim ifadesidir çünkü sql yazmaktan emindik çünkü günlüğün veritabanlarını bekleyemiyoruz ' Artık yaşamlarımızda var.


-1
2017-09-23 13:30



Alternatifiniz için teşekkürler, biraz dar bir görünüm. Uygulama hesabına yalnızca saklı yordamlarda izin verilirse, bağlantı dizesinin bulunması uygulamanın yapabildiği her şeyi yapmanıza izin verir - yalnızca kayıtlı provaları çalıştırın. >> "db'yi geliştiricilerden korumak için ihtiyacınız olan tek şey" burada katılmam gerek. Güncelleme sorunları var, sorunlara neden olan perf. problemler, düzeltilmemiş / belgelenmiş hatalar, test edilmemiş kodlar üretime geçiyor, kod üretimde yanlışlıkla çalışıyor ... ve eminim ki birkaç risk var. Üzgünüm, SQL'de emiyorsun, üzerinde çalışmak isteyebilirsin.
Listelediğin tüm bu nedenlerin çoğunluğu, dağıtım veritabanına erişim problemleri değil, dağıtım sorunlarıdır. Ve ben sql de emmek iyi, eklemek dışında bir şey yapmak için ihtiyacım yok güncelleme seçin. Mantığı veritabanına koyan herhangi bir geliştirici yanlış yapıyor. Veritabanları aptal veri depolarıdır ve böyle davranılmalıdır. - Chris Marisic
Ve evet, exec ile ilgili noktanız olsa da, bana SP'leri veri eklemek, güncellemek ve seçmek ve uygulamanın yapabilecekleri her şeyi yapmak için kullanabilme becerisi verir. Bununla birlikte, sadece “güvenlik” i uygulamaya çalışan çoğu DBA gibi, sadece exec kullanımına izin vermek aptaldır çünkü NHibernate gibi araçları kullanmak imkansızdır. IMO'nun% 90'ının tümü iş koruma amaçlı olup, geliştiricilerin DBA'lara işlerini yapmalarına bağımlı hale getirmeleridir. - Chris Marisic
SP'ler, üretimde çalışmayı sevdiğimiz, test edilmiş kodlardır. İyi haberler, arkadaşım: docs.jboss.org/hibernate/stable/core/reference/en/html/... - Hazırda bekletme3 saklı yordamlar ve işlevler aracılığıyla sorgular için destek sağlar. Aşağıdaki belgelerin çoğu her ikisi için eşdeğerdir. Saklı yordam / işlev, Hazırda Bekletme ile çalışabilmek için ilk çıkış parametresi olarak bir sonuç kümesini döndürmelidir. Oracle 9'daki ve daha yüksek bir depolanmış işlevin bir örneği aşağıdaki gibidir:
>> "Bu malzemelerin% 90'ı, işçilerin korunması için, geliştiricilerin DBA'lara işlerini yapmaları için bağımlı olmalarını sağlamaktır." Burada 60 geliştiricimiz var, bu yüzden işimi tüm uygulamaları için sistemde tutmak, birkaç kaza olduğundan emin olmak ve uygun değişim ve belgeleme prosedürlerini takip etmek. Geliştiriciler işlerini geliştirmede ve testte yapabilirler - üretim güncelleme erişimine ihtiyaç duymazlar. Uygulamalarının tablolarda manuel güncellemelere ihtiyacı varsa, bunun düzeltilmesi gerekir.