Bilinmeyen bir kaynaktan yedeklemeyi geri yüklemenin güvenlik etkileri?

Senaryo : Size bir veritabanı yedeği verilir ve bunu bir sunucuya geri yüklemenizi söylersiniz (zaten diğer veritabanlarını barındırır), ancak yedeğin ne içerdiği veya kaynağa güvenilmesi gerekip gerekmediği hakkında hiçbir faydalı bilgi verilmez.

Soru 1 : Kötü niyetli olabilecek bir yedeği geri yüklemenin olası etkileri nelerdir?

Soru 2 : Sunucunuzu / diğer veritabanlarındaki verileri potansiyel olarak kötü amaçlı bir yedeğin geri yüklenmesinin etkisinden korumak için ne yapabilirsiniz? RESTORE VERIFYONLYiyi bir ilk adım gibi görünüyor. Nihai cevap muhtemelen 'dış dünyaya erişimi olmayan bir sanal alan VM'sindeki veritabanını geri yüklemek' şeklindedir, ancak bu seçeneğin masaya düştüğünü varsayalım. Bu durumda başka ne yapılmalı?

Bir veritabanı zararlı kod içerebilir, muhtemelen "sa" girişi için bir şifreyi değiştirecek veya her veritabanını bırakacak bir prosedür olabilir. Ancak, bir soruna neden olduğunu görebilmemin tek yolu bireyin veritabanını geri yüklemesi ve daha sonra bu veritabanı içinde herhangi bir kodu el ile çalıştırmasıdır. Herhangi bir otomatik şekilde yürütülmez.

Bir veritabanında SQL Server'ın bir sunucuya geri yükledikten sonra veritabanında bazı kod bitlerini otomatik olarak çalıştırması için uygulanabilecek bir ayar yoktur. Öyle olsaydı, Microsoft'un, ürün için Ortak Kriterler sertifikasını kaybedeceğini beklerdim. Bu bana bir DBMS izin vermiş bir hata büyük.

Yapabileceğiniz bazı önleme adımları var.

1. Bir sysadmin'den başka kimsenin geri yüklenen veritabanına erişimi olmadığından emin olun.
2. Geri yükleme tamamlandıktan sonra db'yi tek kullanıcı moduna geçirin.
3. Depolanan tüm prosedürlerin ve işlevlerin içindeki kodu ve bu veritabanının içindeki tetikleyicileri kontrol edin.
4. Bütünlük sorunu olmadığından emin olmak için bir dbcc checkdb yapın.
5. Veritabanına erişimi olan kullanıcıları kontrol edin ve hepsini kaldırın.
6. Sizin tarafınızdan kontrol edilen belirli nesnelerle sınırlı, erişime izin vermeye başlayın.

Shawn'un dediği gibi, vbalid gibi görünen bazı saklı yordamlar başka bir kötü amaçlı kod çalıştırmadıkça kod kendiliğinden çalışmaz. Çoklu kullanıcı moduna geçmeden önce her birinin içindeki kodu kontrol etmenin nedeni budur.

Buraya ulaşıyorum, ancak en az bir tehlikeli senaryo düşünebiliyorum: dosyalanabilir bir veritabanını geri yüklerseniz , bu dosyalar şimdi varsayılan olarak ağınızda (ve özellikle de SQL Server'ınızda). Bir virüsü geri yükleyebilirsin.

Elbette tek başına hiçbir şey yapmaz - virüs aniden duygulanmıyor - ancak kullanıcılarınız o zaman dosyaya erişmeye çalışırsa, virüs bulaşmış olabilir. (Hey, ulaşacağımı söyledim.) Dışarıdaki bir bilgisayar korsanının kapıya kötü amaçlı yazılım almak istediği bir senaryo hayal ediyorum ve sonra da "İşte dosya: \ sqlserver \ filetableshare \ myvirus.exe "- bu noktada, algılama olmadan güvenlik duvarlarınızdan geçti ve şimdi dahili antivirüs ve kötü amaçlı yazılımdan koruma araçlarına bağlıyız.

DİNLENMEYEN VERIFYONLY iyi bir ilk adım gibi görünüyor. Nihai cevap muhtemelen 'dış dünyaya erişimi olmayan bir sanal alan VM'sindeki veritabanını geri yüklemek' şeklindedir, ancak bu seçeneğin masaya düştüğünü varsayalım. Bu durumda başka ne yapılmalı?

Geri yükleme , veritabanının bütünlüğünü doğrular ve doğrular, yedeklemenin kötü amaçlı bir kod içerip içermediğini size bildirmeyecektir, VERİ BİLDİRİMİ GERÇEKLEŞTİRMEK, yedekleme birimlerinde bulunan verilerin yapısını doğrulamaya çalışmaz. Oldukça düşük bir ihtimal, yedekleme çalıştığınız firmanın içinden gelirse kötü niyetli olabilir, ancak bazı üçüncü taraflardan geliyorsa, Shawn'ın işaret ettiği gibi dikkatli olmanız gerekir.

Microsoft Çevrimiçi belgeleri diyor ki

• Güvenlik nedeniyle, bilinmeyen veya güvenilmeyen kaynaklardan veritabanları eklememenizi veya geri yüklememenizi öneririz. Bu tür veritabanları, istenmeyen Transact-SQL kodunu çalıştırabilecek veya şema veya fiziksel veritabanı yapısını değiştirerek hatalara neden olabilecek kötü amaçlı kodlar içerebilir. Bilinmeyen veya güvenilmeyen bir kaynaktan bir veritabanı kullanmadan önce , üretim dışı bir sunucudaki veritabanında DBCC CHECKDB çalıştırın ve veritabanındaki saklı yordamlar veya diğer kullanıcı tanımlı kodlar gibi kodları da inceleyin.

Bu soru çoğunlukla kötü amaçlı yazılım içeren bir yedeklemeye odaklanır, ancak geri yükleme işleminden istenmeyen ve potansiyel olarak kötü niyetli davranışlar elde etmek de mümkündür.

Yanlışlıkla, SQL Server'ın yedekleme dosyasının sonunu okumaya çalışmasına ve çökmesine neden olan bozuk bir yedekleme dosyasını geri yüklemeye çalışarak SQL Server'ın çökmesinin mümkün olduğunu buldum. Hangi sürümlerin hassas olduğundan veya sorunu yeniden oluşturmak için tam olarak neyin gerekli olduğundan emin değilim. Birkaç yıl önce bu sorunla karşılaştığımda bazı sınırlı detayları burada belgeledim .

Bilinmeyen bir veritabanını bilinmeyen bir kaynaktan geri yükleme riski nedir? Yok.

Bilinmeyen bir uygulamanın o veritabanına bağlanmak ve kod çalıştırmaya başlamak için bir sysadmin hesabı kullanarak bağlanmasına izin vermenin riski nedir? ÇOK ŞEY! Uygulama hesabının yalnızca veritabanı içinde hakları varsa ve sunucu düzeyinde erişim yoksa, veritabanının dışında gerçekten yapabileceği bir şey yoktur. Bu temel olarak başlangıçta sunucuda uygun bir güvenlik çerçevesi kurulumuna sahip olmaktan kaynaklanmaktadır.

Bir veritabanı yedeklemesine verilir ve bunu bir sunucuya geri yüklemenizi söylersiniz (zaten diğer veritabanlarını barındırır), ancak yedeğin ne içerdiği veya kaynağa güvenilmesi gerekip gerekmediği hakkında hiçbir faydalı bilgi verilmez.

Güzel. Bunu yapmanı söyleyen ve sonuçların sorumluluğunu tam olarak üstlendiklerini belirten imzalı bir yazılı ifade talep ediyorsun. Bunu yapmak istemiyorlarsa, yedekleme dosyasını inceledikten sonra (mümkünse) yüklemeyi bir sanal alanda test etmeli ve tüm tabloları, prosedürleri vb. İyice incelemelisiniz. Herhangi bir noktada komik kokuyorsa, üretim sistemi. O zaman bile, yedeğe asla güvenmediğinizi ve bunu yalnızca doğrudan emirlerle yaptığınızı açıkça belirtmelisiniz (patronunuz ve üstleri için).

Böyle bir ifade imzalamazlarsa, herhangi bir şey yapmadan önce üstlerini uyar. Bir profesyonel olarak, kararmış zırhlı bir üstlünün yapmanı emrettiği ne olursa olsun, sisteminizi mümkün olduğunca korumak sizin görevinizdir. Kovulabilirsin, ama kafanı dik tutabilir ve doğru şeyi yaptığını bilirsin.

Burada önerilen çok geniş kapsamlı olanlar dışında, söylenen kişi başına bir sürü tehlike yok. Daha önce de belirtildiği gibi, veritabanı yedeklemesinde otomatik olarak yürütme işlemine sahip olmak zordur. Bir çeşit dış tetikleme mekanizmasına ihtiyacı var.

Eski bir dizüstü bilgisayar / masaüstünü ve lisanslama bir sorunsa Veritabanı yazılımınızın (SQLExpress) bir değerlendirme sürümünü edinin. Makineye yedek dosyayı kopyalayın, ağ / kablosuz bağlantısını kesin ve geri yükleme işlemini yapın. O zaman kazmaya başla. İhtiyacınız olan her zaman ayırın, çünkü birçoğu bu konudaki diğer yazılar tarafından kapsanan birçok şey var.

DBA bütünlüğünüz ve Üretim ortamınızın iyiliğini, bir üst tarafından verilen herhangi bir siparişten daha önemlidir.