Neden bir uygulama sa hesabını kullanmamalı

Benim ilk sorum, lütfen nazik ol. Sa hesabının bir SQL Server ve tüm veritabanları, kullanıcılar, izinler vb. Üzerinde tam kontrol sağladığını biliyorum.

Uygulamaların sa şifresini mükemmel, iş odaklı bir sebep olmadan kullanmaması gerektiğine dair kesin bir inancım var. Bu soruya verilen cevaplar, BT odaklı bir tartışma konusundaki nedenlerimin çoğunu içerir

Sa şifresini kullanmadığı sürece işe yaramayacak yeni bir servis yönetim sistemini kabul etmeye zorlanıyorum. Neden bir değerlendirme hazırlarken neden sunucu ile uğraşmak için zamanım olmadı ama sunucu ekibi sabit bir rol kullanmaya çalıştı. Db_creater ve gerektireceğini düşündüğüm diğer izinleri bir araya getirerek kurdum. hangi başarısız oldu. Daha sonra sunucu ekibinin sa hesabını yüklemesine izin verdim ancak veritabanı için dbo rolünde bir hesap altında çalışıyorum ancak bu da başarısız oldu. Korkunç bir şekilde, sysadmin rolündeki bir hesapla çalışmasını sağlamaya çalıştım, ancak bu bile başarısız oldu ve elimde olduğumdan daha fazla zaman harcamadan neler olup bittiğini çözmemi sağlayan yararlı hata mesajlarıyla değil. Sadece sa hesabında ve config dosyasında açık metin olarak kaydedilmiş parola ile çalışacaktır.

Bunu sorguladığımda ve sunucu ekibi satıcıyla konuştuğunda, 'Bununla ilgili sorun ne?' ve sonra 'peki şifreyi karıştırmaya bakabiliriz' ffs

Dosyaya erişimi kısıtlamanın yolları ve araçları olduğunu biliyorum ama bence güvenlikteki başka bir zayıflık.

Her neyse, sorum şu ki, birileri bana bunun neden kötü bir şey olduğunu ve neden büyük bir hayır olması gerektiğini işletime açıklamak için kullanabileceğim bazı belgelere işaret edebilir. Ben, güvenliği ciddiye almam gerektiği ve işi anlamak için uğraştığım ve nihayetinde yine de sıra dışı olabileceğim anlamına geldiği bir alanda çalışıyorum ama denemeye ihtiyacım var.

Bu iş bağlıdır, ancak çoğu durumda en önemli şey emin emin olmaktır değil bir BT sorunu olarak görülen. Bu bir güvenlik meselesidir ve iki üst üste gelen iş insanı, "güvenlik" derseniz, yalnızca "genel BT olayları hakkında sızlanmaktan" bahsederseniz dinlemeniz daha muhtemeldir.

Güvenlik gereksinimi olan herhangi bir müşteriyle çalışıyor musunuz? Bu başlamak için iyi bir yer. Özel erişim erişimi olan bir uygulama çalıştırırsak veya özel erişimini kullanmasam bile kimlik bilgilerini düzgün bir şekilde korumamış olan bir uygulama çalıştırırsak (mümkün olduğunda depolanan kullanıcı / geçiş yerine Windows Tümleşik'i şiddetle tercih ederiz) ve bir güvenceye maruz kaldık Denetim, bu denetimin başarısız olacağını ve müşterilerimizi kaybetme riskini taşıyacağımızı ve / veya gruplarımızın müşterilerine (çoğunlukla çalıştığım üründe bankacılık kuruluşları, grubun diğer bölümlerinde polis ve sağlık ile ilgilenenlere geri ödeme yapmak zorunda kalacağız) yetkililer ve benzeri) güvenlik, amacımız için uygun olma teklifimizin bir parçasıdır. İş adamları , BT tavsiyelerine genellikle daha fazla hizmet etmemekle birlikte, bu potansiyel tehdidin ciddiyetini anlayacaklardır.

Müşterinin dayattığı gereksinimleri görmezden gelmek bile, çeşitli endüstri standardı güvenlik standartlarını yerine getirmeye çalışırsanız, o zaman yine bu tür bir uygulama kimlik doğrulaması, genel olarak kabul edilen en iyi uygulama olduğu kadar çok bir denetim karşısında başarısızlığa uğrayacaktır. "sadece yapılmamalı" listesinde. İş karar vericilere, güvenliğin uygulamanın önemli bir parçası olduğunu ve bu satıcının farkında olmadığı göründüğü (veya en azından uygun şekilde endişe ettiği) gerçeğini açıkça belirtin. ile başa çıkmak: DB güvenliğini bilmek en iyi uygulama işinin bir parçası olmak (ve, olması gerektiği) ve bunu yapmak zor değil.

Ayrıca, (alıcının) başka türlü değil satıcıya makul güvenlik gereklilikleri dikte etmeniz gerektiğini de belirtin . Bu, sizin verilerinizdir, bu nedenle yeterince güvenli olduğu düşünülenlerini belirtme konusunda nitelikli değillerdir.

Hiçbir uygulamanın SA erişimi olması gerekmez - hiç. (Tek amacı bir tür veritabanı yönetimi değilse.)

Hiçbir girişe (uygulama veya kişisel), girişin sahip olması gereken işin gerektirdiğinden daha fazla hak vermemek genel bir kuraldır.

Hiçbir uygulama tamamen güvenli değildir. Çoğu, bir tür SQL Injection veya XSS güvenlik açığına sahiptir. Bir davetsiz misafir, seçtiği bir beyanı yerine getirir ve 'SA' erişimi varsa, verilerinizi, işi anında öldürebilecek birçok şey olabilir. (Özellikle verinin güvence altına alınması gerekiyorsa, çünkü kanun uygulayıcı tarafından kullanılır.) Söz konusu kişilere ne yapmaları gerektiğini, birinin tek bir rekoru bile kasten değiştirebilmesi ve bu bilgilerin sızdırılmış olup olmadığını sor.

Şimdi, 'SA' erişimiyle, yalnızca uygulamanın veritabanı değil, sistemdeki diğer tüm veritabanı da değiştirilebildi. Bu nedenle, TÜM veritabanlarının bir kopyasını alıp gazeteye gönderirseniz, paydaşlarınıza ne yapacaklarını sorun. Çünkü hoşnutsuz bir çalışan bu güvenlik boşluğunun var olduğunu tespit ederse olabilir.

Satıcı, şifreyi çözebileceklerini söyledi. Bu BS. Uygulamanın kullanabilmesi için şifreye cleartext yoluyla erişmesi gerekir, böylece şifreyi çözmenin anahtarı hemen yanında şifreli olarak saklanır. Ayrıca, daha önce de belirtildiği gibi, asıl sorun bu şifreyi bulan bir kişi değildir; bu sistemi bir güvenlik açığı kullanarak kullanan (yanlış) kişilerin, hiç bir şifre görmeden tüm veritabanlarınıza tam erişim sağlayacağıdır.

SA'nın gerekli olmasının en olası nedeni, uygulamanın SQL Agent ile etkileşime girmesi gerektiğidir. En azından bu doğru uygulamak için zor işlevlerden biridir ve çoğu insan sadece onu kullanmak için "SA kullanın" rotasını kullanır. 'SA' isteğinin kendisi, satıcının sysadmin izinlerini nasıl kontrol edeceğini bilmemesinden kaynaklanıyor olabilir.

Deneyebileceğiniz iki çözüm var:

1. SA'yı (yine de en iyi güvenlik uygulaması) yeniden adlandırın ve 'SA' adı verilen sınırlı haklarla yeni bir hesap oluşturun. (Bunu hiç denemedim, ama çalışması gerekiyor)

2. Yazılımı yüklemeyin. Profesyonel bir kişi olarak bu eylemin sorumluluğunu üstlenemezsiniz, bu yüzden yüklememelisiniz. Size bir karşılaştırma yapmak için, bir boru tesisatçısından, biraz boru / para tasarrufu yapmak için gaz hattını etrafındaki yerine doğrudan şömineden geçirmesini isteyin. Bu görüntüye gülüyorsun, ama uygun bir karşılaştırma olduğuna inanıyorum - Bu yazılım er ya da geç patlayacak, muhtemelen er ya da geç. Ve bunu yaptığında işi de mahvedebilir.

Bunların hepsi "onları" bu yazılıma ihtiyaç duymazlarsa, size verebileceğim son tavsiyedir. Verilere bir şey olursa, ilk sorumlu tutulan sen olacaksın. Yani, bu uygulama yerinde olduğunda muhtemelen herhangi bir iş güvenliğine sahip değilsiniz, bu yüzden en azından bazılarını veren bir işveren bulun.

Buna iki saldırı hattı görüyorum.

• Uyum . Mağazanızda yürürlükte olan zorunlu uyum kriterleri var mı? İfadeleri üzerinden dikkatlice araştırın ve 'gereksinim' uygulamasıyla uyumlu olmayan bir şey bulup bulamadığınızı görün. Bir sauygulama tarafından kullanılmasını önleyen herhangi bir şey bulursanız , uygulama işinizi vb.

• Kullanıcı Yönetici Erişimi . Emin açıkça olgu sunulmuştur olun gerektirir bir uygulama sao verir yürürlükte erişimi sauygulamasının yüklü olduğu iş istasyonlarında yönetici haklarına sahip tüm kurumsal kullanıcılara erişim. saParolayı uygulamanın çalıştığı yerel yöneticilerden gizlemenin bir yolu yoktur , bu bir gerçektir ve hiçbir 'çırpma' bunu engelleyemez. İsterse, yerel bir yöneticinin ulaşamayacağı hiçbir yerel güven kaynağı yoktur. saGerektiren bir uygulamanın olmasının sa, uygulamayı çalıştıran tüm kullanıcılara ayrıcalıklı vermeyle eşittir . Bunun ne anlama geldiğini, kullanıcıların ne yapabileceklerini açıklayın:

  • Sunucudaki herhangi bir veriyi, sadece bu uygulamadan değil, o sunucuda barındırılan herhangi bir veri tabanından da okuyabilme
  • Sunucudaki herhangi bir veriyi aynı sunucudaki herhangi bir veri tabanından tekrar değiştirme yeteneği
  • Değişiklik yapıldıktan sonra davranışlarından herhangi bir izini silme yeteneği
  • Belirli işlemlerin farklı bir kullanıcı tarafından yapıldığını ortaya koymak için herhangi bir denetim ve geçmişi değiştirme yeteneği
  • Bu sunucuya güvenen herhangi bir kaynağa yapılan saldırıyı artırmak için SQL Server kimlik bilgilerini kullanma yeteneği . Bu, başka herhangi bir SQL Server'ı ifade edebilir ancak dosya paylaşımları dahil ancak bunlarla sınırlı olmamak üzere diğer kaynaklar da olabilir; çünkü Borsalar sunucular vb., SQL Server bir basamak taşı olarak kullanılabilir.

Karar vericilere, bu uygulamayı kabul etmenin , yukarıda belirtilen tüm ayrıcalıklarla uygulamayı çalıştıran iş istasyonlarına yönetici erişimi olan her çalışanın emanet edilmesi anlamına geldiğini açıkça belirtin . Satıcı sa, uygulamanın şifresini 'şifrelemekten' başka türlü veya başka birini çağırarak standını savunmaya çalışacaktır . Bu su tutmaz. Bir yöneticinin saldırısına dayanabilecek bir şifreleme düzeni yoktur. Yerel olarak 'gizli' bir şifre bulmak için gereken teknik beceri miktarının tamamen alakasız olduğunu açıkça belirtin. Çalışanlar bunu kendi başlarına yapmayacaklar, onlardan biri google'a çıkacak ve kullanımı kolay senaryoyu keşfedecek.

İlk olarak, sa şifresi düz metin sakladı Cüzdanına oy vermelisin. Bunun kabul edilebilir olduğunu düşünen kişi, işinden çıkarılması gerekiyor.

Sorunu açıklamanıza yardımcı olabilecek bir anoloji: Çalışanın Alice'in birinci kata erişmesi gerekiyor. Ona tüm binanın ana anahtarını mı yoksa birinci katın anahtarını mı veriyorsun? Cevap: Ona sadece birinci katın anahtarlarını ver. Niye ya? Çünkü kazara veya kasıtlı hasar olasılığını azaltır. Alice ilk etapta ikinci kattaki sunucu odasına gidemezse, o zaman orada asla kötü bir şey yapmaz.

En Az Ayrıcalık İlkesidir.

Uygulamanın niçin sa hesabını kullanması gerektiğine ilişkin olarak, bu PerfMon veya Extended Events'in yanıtlayabileceği bir sorudur. T-SQL şablonunu kullanarak bir PerfMon izi oluşturun, belki uygulama adına göre filtrelenir.

Başımın üstünde, sa kullanmaya karşı başka bir argüman var: sa hesabının kullanılması, SQL Server hizmetinin karma kimlik doğrulama modunda olmasını gerektirir. WIndows sadece kimlik doğrulaması daha iyidir çünkü Kerberos'un tüm güvenli özelliklerinden faydalanabiliriz.

Teknik açıdan, bir uygulamanın SA izinlerine ihtiyaç duyması için hiçbir neden yoktur. Muhtemelen olan, uygulamanın geliştiricilerin girişlerinin sysadmin izinlerine sahip olup olmadığını kontrol etmeleridir ve eğer değilse bir hata mesajı atarlar. Bu şekilde, uygulamanın SA hakları gerektirdiğini iddia edebilirler.

Bu uygulamaya sahip olmanız gerekiyorsa, üzerinde başka hiçbir şey olmayan ayrı bir durumda çalıştırırım.

Belki de satıcınız "sa" talep ediyor / talep ediyor çünkü uygulamalarında bir yerde XP_CMDSHELL kullanıyorlar. (XP_CMDSHELL'e sınırsız erişimle mümkün olan hasarı başlatmama izin vermeyin. Bunun potansiyel olarak yalnızca verilerinizi değil, ana makineyi ve belki de ağınızdaki yönetici benzeri erişime açık olan herhangi bir şeyi açtığını söyleyin)

Yasal bir ihtiyaç varsa, bir vekil hesap üzerinden kısıtlı erişim verebilirsiniz. Örneğin, BOL'a bakın: http://msdn.microsoft.com/en-us/library/ms175046.aspx

Hiçbir uygulama SA hesabının ve şifrenin çalışmasını gerektirmemelidir.

Bununla birlikte, bir IT Servis Yönetimi ürünü kurdum ve kurulum işlemi sırasında yükleyicinin DB'yi oluşturmasına ve yazılımın kullanması için DB'ye bir hesap eklemesine izin vermek için SA hesabı kimlik bilgilerini sağlama seçeneğine sahipsiniz. SA hesap bilgileri uygulamada saklanmaz veya herhangi bir yerde yükleyici günlükleri. Bu yazılım ayrıca yükleme sırasında önceden oluşturulmuş bir veritabanı kullanma seçeneği sunar.

Bu yüzden, kurulum için veya bu BT Servis Yönetimi yazılımının çalıştırılması için SA hesabının gerekli olup olmadığını onaylarım.

Eğer Kurulum: geçici bir 'sa' hesabı oluşturun - kurulumu yapın - ve hesabı kaldırın.

Eğer İşlem: Bu veba gibi bir yazılımı kullanmaktan kaçının. (veya yalnızca bir veritabanını barındıracak bağımsız bir SQL sunucusu kurun.)

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 parola ilkesini zorlar - parola uzunluğunu, ömrünü ve geçmişi denetler. 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.