Geliştiricinin dizüstü bilgisayarlarına kritik bir veritabanı depolamak için iyi bir güvenlik uygulaması nedir?

33

Birkaç sorumuz var:

Geliştiricilerin, makinelerindeki üretim veritabanının bir kopyasına ihtiyacı vardır.
Geliştiriciler, App.config dosyalarındaki söz konusu veritabanının şifresine sahiptir.
Söz konusu veritabanındaki verilerin tehlikeye girmesini istemiyoruz.

Önerilen birkaç çözüm ve sakıncaları:

Tam disk şifreleme. Bu, tüm sorunları çözer, ancak dizüstü bilgisayarın performansını düşürür ve biz bir başlangıçız, bu nedenle powerhorses için paranız yok.
Şifrelenmiş sabit diskli bir VM oluşturmak ve veritabanını depolamak. İyi çalışıyor, ancak Web.Config'de bir parola olduğundan çok yardımcı olmuyor.
Çözüm numarası 2 +, geliştiricinin her şeyi çalıştırdığında veritabanı şifresini yazmasını gerektiren. Tüm sorunları çözer, ancak uygulamayı dakikada bir kaç kez başlatan geliştiriciler için gerçekten zahmetlidir. Ayrıca, aynı veritabanına bağlanan birden fazla uygulamamız var ve bir şifre ekranının uygulanması her birinde farklı olacak.

Öyleyse benim sorum, bu tür bir soruna ortak bir çözüm veya yukarıdaki çözümlerden herhangi birinin uygulanabilir hale getirilmesi konusunda herhangi bir öneriniz varsa?

database security

— Svarog
kaynak

26

Aslında tam disk şifrelemenin performans etkisini ölçtünüz mü? Oldukça eski dizüstü bilgisayarlarda kullanıyorum ve önemli bir performans düşüşü tanımadım. Modern işletim sistemleri önbellekleme konusunda oldukça iyidir ve diskler yine de yavaşlar. En kötü etki muhtemelen pil ömrünüz üzerinde.

— 5gon12eder

69

Dürüst olmak gerekirse, bu doğru bir yaklaşım gibi görünmüyor. 1) Devs neden makinelerinde üretim veritabanına ihtiyaç duyuyor ? Dev db için yapay veri oluşturmanın bir yolu yok mu? 2) Şifre neden bir yapılandırma dosyasında düz metin olarak saklanıyor? Kusursuz bir sürece bir bandaid koymaya çalışıyorsunuz, öyle görünüyor. Belki de dev makinelerde gerçekte yaşayanları ve şifrenin veritabanına nasıl kaydedildiğini gözden geçirebilirsiniz.

— Thomas Stringer

2

Geliştiricilerin üretim veritabanına ihtiyaç duyma nedenleri vardır. Tarihsel nedenlerden dolayı çalışmaları canlı verilerle çok yakından ilişkili. Bunun kötü bir fikir olduğunu biliyorum ve iyi bir çözüm bulamazsak yapay verilere geçeceğiz. Şimdilik onsuz iyi bir çözüm bulmaya çalışıyorum.

— Svarog

6

MacBook Pro'nun hiçbir kullanıcısı, makinenin hızından SSD sürücüsünde tam disk şifrelemenin açılıp kapatılmadığını size söyleyemez. Fark yok. Hiçbiri farketmez. Belki bir tane ölçebilirsiniz, ama fark edilebilir hiçbir şey yok.

— gnasher729

5

Ikinci @ gnasher729 adlı kullanıcının yorumu. Düzenli ortamlarda (finansal ve sağlık) uzun yıllar boyunca tam disk şifreleme kullanmış olması, performans üzerinde gözle görülür bir tahliye olması gerekmez. Pek çok insan başka geçerli noktaları ortaya koyuyor, ancak HIPAA ortamında, veritabanları not defterlerine yerleştirilmemiş olsa bile, tam disk şifrelemesi olmadan makul bir politikaya sahip olmak zor. E-postalar ve diğer veri parçaları çoğu zaman yine de orada ortaya çıkar. Dosyaları değiştirin .... vb ... Tam Disk Şifrelemesi yeterli değil, ancak genellikle gerekli.

— 15'de joshp

100

Yalnızca üretim veritabanının bir kopyasını istemezsiniz, aslında yasadışı da olabilir. Örneğin, ABD'de, kişisel sağlık verileri, finansal veriler ve hatta kimlik hırsızlığında kullanılabilecek veriler gibi düzenlenmiş bilgiler içeriyorsa, üretim verilerini üretim ortamından çıkaramazsınız. Bunu yaparsanız, para cezasına çarptırılabilir, uyumluluk durumunuzu kaybedebilir ve bu nedenle daha agresif denetimlere tabi tutulabilir, hatta bir davada isimlendirilebilirsiniz.

Test için üretim ölçekli verilere ihtiyacınız varsa, birkaç seçeneğiniz vardır:

Tüm yapay verileri oluşturun. Bu göründüğünden daha zor. Mantıklı hayali veriler üretmek şaşırtıcı derecede zor ve emek yoğundur.
Üretim verilerinizi anonimleştirin. Bu daha kolay olabilir, ancak dikkatli olun.

Seçenek # 2 için

Üretim ortamında, yetkili bir veritabanı yöneticisi, üretim verilerinin bir kopyasını çıkarır.
Yine de üretim ortamında, aynı yetkili yönetici tüm hassas verileri anonimleştiren bir yordam yürütüyor. Şüpheniz varsa, anonimleştirin.
Ancak o zaman veriler başka bir ortama taşınmalıdır.

— Corbin March
kaynak

31

ve veritabanı kopyasının parolası üretim sürümündeki parola ile aynı olmamalıdır .....

— Monica

3

“Örneğin, ABD’de, düzenlenmiş bilgiler içeriyorsa, üretim verilerini üretim ortamından çıkaramazsınız” Ne? Bunun için kaynağın var mı? Örneğin, bir üretim veritabanının yedekleme ortamını evreleme ortamı için veri olarak ya da geliştirici makinelerinde dbs testi olarak kullanamaz mısınız?

— dadı

12

@ nanny Düzenlenmiş verileri kullanıyorsanız. Örneğin, HIPAA düzenlemesi altında çalıştım. HIPAA, "Kapsanan kuruluşlar ayrıca, belirli amaçlarla ne kadar korunan sağlık bilgisinin kullanıldığını, açıklandığını ve talep edildiğini sınırlayan makul minimum gerekli politika ve prosedürleri de uygulamalıdır." Gerekli olan asgari politika, bazı yorumlara açıktır. Hukuk danışmanımız, geliştiricilerin erişemediği yerlerde bulunan hassas verileri tutan katı bir yorum önerdi. (İşlerini yapmaları gerçekten gerekli mi?) Aynı uyarı, PCI gibi finansal uyum için de geçerlidir.

— Corbin

4

@nanny Bunu avukat olmayan bir avukatın görüşüne göre alın, ancak anladığım kadarıyla, kurallar eyaletlere göre büyük ölçüde değişir. Çalıştığım hukuk müşaviri her zaman dikkatli ol. Açıkçası, devs görevlerini yerine getirmek için gerçek SSN'lere ihtiyaç duymaz , bu nedenle avukat bu SSN'lerin devlerin onlara erişemeyeceği korumalı bir ortamda yaşamalarını önerir. Yine de beni dinleme. İçin bakan bir avukat sizin uzun vadeli çıkarları iyi bir kaynak olacaktır.

— Corbin

5

Açıkça söylemek gerekirse, hükümet işi yapmadığınız sürece ÜFE ile dikkatsiz olmak YASAL DEĞİLDİR, sonra Başlık 32 devreye girer ... ama bu ciddi bir hukuki sorumluluk riskidir. Aksi halde bu harika bir cevap. upvoted.

— dwoz

9

En azından veri merkezinizdeki geliştiricilerin VM'lerini bu çalışma için RD olarak değerlendirmelerini sağlayabiliyor musunuz? Gerçekten de üretim dışı verilerden çalışıyor olsalar da, veriler kolayca çalınan dizüstü bilgisayarlarda saklanmadığından, oraya ulaşana kadar bu daha güvenli olacaktır.

— Brian Knoblauch
kaynak

Bu bir yorum gibi daha fazla okur, Nasıl

— Cevaplanır

5

@gnat, bu cevap kısa olabilir ama çok iyi bir önerilen alternatif.

Böyle bir sakal olma, @gnat ... bu iyi bir cevap.

— dwoz

@ dan1111 Sorun bu. Bu bir cevap değil. Bu bir alternatif. Bu bir yorum yapar, cevap değil.

— corsiKa

2

@ CorsiKa, sorunun öncülünü zorlayan cevaplara izin verilir ve genellikle çok iyi cevaplardır. XY problemine bakınız: meta.stackexchange.com/questions/66377/what-is-the-xy-problem . Daha ayrıntılı cevaplar daha iyi olabilir, ancak bu hala bir cevap.

8

Mümkünse çalışma şeklinizi değiştirin.

Diğerlerinin dediği gibi:

Geliştirme için üretim verilerinin kullanılması iyi bir uygulama değildir.
Düz metin olarak kaydedilmiş bir şifreye sahip olmak iyi bir uygulama değildir.

Her ikisi de sizi önemli risklere maruz bırakır ve mümkünse değiştirilmeleri gerekir. Bu değişiklikleri yapmanın maliyetinin ne olacağını en azından ciddi bir şekilde değerlendirmelisiniz. Bu, değiştirme gücünüz olmayan bir dış bağımlılık ise, bunu bu kime sahip olana yönelik bir endişe olarak düşünün.

Gerçek dünyada, bunu değiştirmek gerçekten mümkün olmayabilir. Yaptıklarınızın yasal olduğunu varsayarak, bu düzenlemeyle yaşamak zorunda kalabilirsiniz (en azından geçici olarak).

Bu gerçekten gerekliyse, sadece tam disk şifreleme yapmanız gerekir.

Riskler göz önüne alındığında, mevcut en iyi güvenlik seçeneğini kullanmanız gerekir ve budur. Bir performans hit varsa, onunla yaşa. Hassas verilerle çalışmanın maliyetidir.

Müşteriniz olsaydım, verilerimle mevcut en iyi güvenlik seçeneğini kullanmamaya karar verdiğinizden etkilenmezdim, çünkü dizüstü bilgisayarlarınızı biraz daha yavaşlattı.

1

"Tamamen aptalca bir fikir" için "İdeal bir çözüm değil" değiştirilmeli IMO

— Darkhogg

@Darkhogg, haklısın daha güçlü olması gerekiyor. Düzenlenen. Uygulamanın ne kadar hassas olduğunu bilmeden "tamamen aptal" olduğu kadar ileri gitmem. Pratik olarak, tam disk şifrelemesi kullanılıyorsa, riskten ödün verme riski çok düşüktür, bu nedenle güvenlik sorunu olarak çok fazla şey yapmak mümkündür.

Birinci noktaya katılıyorum, ikincisi değil. Eğer şifrenizi düz metin olarak saklamıyorsanız (1) şifreli metni veya (2) beyninizi nerede saklıyorsunuz? Eğer (1) ise şifre şifresini nerede saklıyorsunuz (sonsuz döngü algılandı). Eğer (2), umarım servisi yeniden başlatmak için şifreyi girmek üzere sabah 2: 00'de uyanmayı seversiniz.

— emory

1

Corbin March'ın cevabı oldukça iyi, ek bir detay daha ekleyeceğim, genelde üretim veritabanınızda iki sınıf veri bilginiz var: sistem / uygulama meta verileri; ve istemci kullanıcı verileri / işlem verileri. Bu sonuncusu ASLA bir geliştirme ortamında "olduğu gibi" kullanılmamalıdır.

Gerçekten de geliştirme yapmak için gerçek üretim istemcisi bilgilerine ihtiyaç duymanız çok nadirdir.

Bununla birlikte, OP'nin burada tarif ettiği sorun ticari sır verilerini veya müşteri verilerini içermeyen yüksek oranda özel sistem verilerini içeriyorsa, bunun için devs tarafından gerekli olan ... güvenlik yaklaşımı olmayan bir şema içermelidir. db şifresi, bir kaynak dosyasındaki açık metinde tutuldu. Örneğin, diskte depolanmayan günlük bir şifreyi yeniden oluşturma mekanizması olması gerekir.

— dwoz
kaynak

5

client user data/transactional data... should NEVER be used in a development environment "as is." - Bu bana işe yaramaz geliyor. Belirli bir müşterinin verileriyle ilgili olan üretim ile ilgili programlama sorunları, bu düzenleme kapsamında çözülemez olacaktır. Ayrıca, gerçek canlı veriler test açısından son derece yararlıdır. Özelleştirme veya anonimleştirme çabası yalnızca özel olarak düzenlenmiş verilere odaklanmalıdır.

— Robert Harvey,

@RobertHarvey, yalnızca üretim sorununu dev bir ortamda çoğaltamazsanız kullanılamaz. Kariyerim boyunca (uzun) Birkaç parmağa, test verilerinin uygun bir şekilde sterilize edilmiş test verisinin bir üretim hatasını üretmek için yeterli olmadığı kadar güvenebileceğimi düşünüyorum. "Özel İşletme Bilgileri", SSN'lerin ve CC numaralarının çok ötesine geçer!

— dwoz

4

Ancak bu rotadan geçecekseniz, işlerini yapamayacak BT çalışanlarına sahip olacaksınız çünkü her şeye Yönetici erişimine sahip değiller. Bunun potansiyel Snowden sorunlarına yol açtığını kabul ediyorum, ancak güvenebileceğiniz insanları işe almak dışında uygulanabilir bir alternatif göremiyorum. Sarbanes Oxley ve HIPAA, hangi tür verilerin saklanması gerektiğine dair çok spesifiktir ve uzun sürelerle değil, "tüm üretim verilerini" içermez. Bununla birlikte, hiçbir şekilde dolaşım dizüstü bilgisayarlarında üretim verilerinin bulunması gerektiğine inanmıyorum.

— Robert Harvey,

1

ASLA için -1. Daha ayrıntılı yorumlarınız cevabınızdan daha iyidir; Onları düzenlemelisin.

1

@ dan1111 o zaman katılmıyorum kabul edebiliriz. "Olduğu gibi" müşteri verileri ASLA ASLA ASLA ASLA kullanılmamalıdır. Her zaman sterilize edilmelidir. Buna inanmıyorsunuz çünkü bu kuduz gelincik tarafından henüz ısırılmamışsınız ... ve olan bu, ne zaman olduğu. Kanınızı çekmek isteyen kuduz deli bir kemirgen. Tavsiyemi al, kuduz mongoose kaçının.

— dwoz

1

Hangi veritabanını ve hangi ortamı belirtmiyorsunuz?

Entegre güvenlik kullanabiliyorsanız, o kullanıcı olarak giriş yapmadan veritabanına erişilemez. Evet, eğer veri sabit diskte ise, saldırıya uğrayabilir, ancak bu birinci seviye bir savunmadır.

App.config, bunun bir .NET olabileceğini düşünüyorum. Config'i bir başparmak sürücüsüne yerleştirin ve başparmak sürücüsünden okuyun. Sürücü mevcut değilse, kullanıcı şifresini şifre ile girin.

Şifreyi ilk girildiğinde ve herkes tarafından okunduğunda hafızada saklamanın bir yolu var mı? Yine çevreyi belirtmiyorsun. Bellek Eşlenmiş Dosyalar

Bazı TDE'lerle anahtarı ayrı bir cihaza kaydedebilirsiniz, böylece veritabanı sunucusu başlatıldığında anahtarı sağlarlar.

— paparazi
kaynak

0

Olası seçeneklerden biri veritabanının bir kopyasını çıkarmak ve bu kopyayı bir komut dosyasıyla ovarak temizlemektir, böylece üretimde olandan farklı veriler elde edersiniz. Üretim ile aynı verilerle sonuçlanmayacaksınız, ancak aynı ölçekte olacaksınız.

— Jason Crosby
kaynak

bu sadece bir hafta önce yapılan en iyi cevabı yapılan ve anlatılan noktayı tekrar ediyor gibi görünüyor

— gnat