Veritabanındaki verileri şifrelemeli miyim?


16

Hasta bakımı, hastaları yönetmek, danışmak, tarih, takvimler, bununla ilgili her şey hakkında bir Web uygulaması yapacağım bir müşterim var.

Sorun, bunun hassas veriler, hasta öyküsü ve benzeri olmasıdır.

İstemci veriyi veritabanı düzeyinde şifrelemede ısrar ediyor, ancak bunun web uygulamasının performansını kötüleştireceğini düşünüyorum. (Ama belki bu konuda endişelenmemeliyim)

Sağlıkla ilgili konularda veri koruma ile ilgili yasaları okudum (Portekiz), ancak bu konuda çok spesifik değilim (sadece bunları sorguladım, yanıtlarını bekliyorum).

Aşağıdaki bağlantıyı okudum , ancak sorum farklı, veritabanındaki verileri şifreleyip değiştirmemeliyim.

Verileri şifrelemede öngördüğüm bir sorun, bir anahtara ihtiyacım olacak, bu kullanıcı şifresi olabilir, ancak hepimiz kullanıcı şifrelerinin nasıl olduğunu (12345 vb.) Ve depolamak zorunda kalacağım bir anahtarı üretiyoruz. bir yerde, bu programcı, dba, ona ne erişebilirse, bununla ilgili herhangi bir düşünce olduğu anlamına mı geliyor?

Kullanıcı şifresine rastgele bir tuz eklemek bile her zaman erişebildiğim için sorunu çözmeyecek ve bu nedenle verilerin şifresini çözebiliyorum.


1
Daha çok istemci tarafı geliştiriciyim, ancak aynı anahtarı kullanıyorsanız her şeyin şifrelenmesinin verileri daha az yapacağından şüpheleniyorum.
Erik Reppen

4
veritabanının tamamını şifreli bir birime koyabilir ve bir gün olarak çağırabilirsiniz. Tabii ki okumalar / yazma işlemleri daha yavaş olacaktır, ancak diskteki veriler şifrelenmişken RDMS'nin (veya kullandığınız her şeyin) tüm avantajlarından faydalanırsınız
DXM

2
Bu aynı zamanda mysql çalışma tezgahındaki verileri göremeyeceğiniz anlamına mı geliyor? Hata ayıklama için en iyisi.
Manoj R

4
Medikal oldukça düzenlenmiş bir endüstridir. Orada çalışan profesyoneller, birinin onlara kuralların ne olduğunu söylemesini sağlar. Bu zihniyet, BT projelerine yayılma çadırları. Bu gerçekten bir güvenlik sorunu değil. Bu kültürel bir mesele. Tıp alanında iş yapmanın maliyeti.
Reactgular

1
İngiltere'de bir hastane 300.000 £ 'dan fazla para cezasına çarptırıldı çünkü disk sürücüleri şifrelenmemiş veritabanları içeren yoldan saptı. Sağlık bilgileri çok hassastır.
MarkJ

Yanıtlar:


9

Bu yasaları bizzat kontrol ederim. Verilerin şifrelenmesi gerekiyorsa, şifrelenmesi gerekir.

Yine de herhangi bir rehberlik almazsanız, hasta ile verileri arasındaki bağlantıyı korumayı amaçlıyorum. Yani büyük olasılıkla PatientIDveritabanı boyunca tablolarda kullanılan bir var. PatientIDbir hastayı, sadece hastanın tıbbi geçmişini vb. tanımlamaz ... Ancak, PatientIDRua de São Bernardo Lizbon'da yaşayan Joe Bloggs olarak tanımlamak için yapabilseydim bunu ayrı bir DB'de tutardım. Hastanın kişisel bilgileri için TDE'yi kullanın ve web uygulamanızdaki anahtarları kullanarak bunun üzerine şifrelemeyi düşünün.

Hastaları tanımlama aracı olmadan bu tıbbi verilerin çalınması son derece utanç verici olsa da, bunun ötesinde bir şey olması pek olası değildir. Bu anonimleştirilmiş tıbbi verileri kullanan kelimenin tam anlamıyla çevrimiçi yarışmalar var.

Tıbbi verilerin hastanın kişisel detaylarından ayrılması ile. Personeli sadece ihtiyaç duydukları şeyle sınırlamak için sağlam bir rol seti kullanın. Hastayla doğrudan ilgilenmesi gereken tıbbi personel (ön hat hemşireleri ve doktorlar) dışında hiç kimsenin ikisine de erişimi olmamalıdır. Resepsiyon görevlileri sadece hastanın kişisel bilgilerine ihtiyaç duyarlar, laboratuvar personeli sadece tıbbi kayıtlara ve PatientID'ye, cerrahi hemşireler sadece şu anda tıbbi durum ve adına ihtiyaç duyarlar.

Her rol grubunu belirlediğinizde, bunları yalnızca web uygulamanızda değil, veritabanında ve ek bir güvenlik katmanında da uygulamayı hedefleyin.


1
IANAL, ancak IMO üyeleri olası sorumluluk büyük olduğunda "yasaları kontrol etmemelidir". Bir avukata danışmalılar.
kevin cline

gerçek bir cevap olarak bu yaklaşım ile gitmek .. ne hasta ne de doktor ile ilgili tıbbi kayıtlar referans ve ne de uydurma olduğunu kanıtlamak istatistiksel analiz için bile anlamsız ve kullanılamaz.
Zalaboza

13

Evet, veritabanını şifrelemelisiniz.

Saklanan veriler için temel şifreleme ("beklemedeki veriler") Genel Olarak Kabul Edilen Güvenlik İlkesidir ve ülkenizde kişisel veya sağlık bilgilerini koruyan yasalar varsa muhtemelen yasalar tarafından zorunlu kılınmıştır.

SQL Server 2008 kullanıyoruz, bu yüzden Microsoft'un TDE'sini kullanıyoruz; MySQL için bazı üçüncü taraf çözümleri olabilir veya belki de sadece bir genel birim şifreleme yaklaşımı (TrueCrypt gibi) işe yarayacaktır (ancak bir veritabanıyla kullanım için onaylanmış bir şeye sahip olmak isterim).

Düzgün yapılırsa, performans isabeti küçük olmalıdır.

Bu arada, bahsettiğiniz bağlantı (hassas bilgilerin ayrılması ile ilgili) temel veritabanı şifrelemesinin üstünde düşünmeniz gereken bir şeydir.

EDIT: Yukarıda belirtilen şifreleme birimi şifreleyecektir. Birisi sabit diski çalsaydı, şifrelenmiş verileri bulurlardı. Ancak, birisi veritabanında sorgular çalıştırırsa, şifrelenmemiş verileri görürlerdi (bu yüzden OP bu konuyu tartışmak istemese de bilgi ayrılmasından bahsettim).

Bu önerinin, yapmanız gereken en düşük düzeyde olması gerektiğini unutmayın. Yasal tavsiye istiyorsanız, elbette başka bir yere bakmanız gerekir. Güvenli kod yazma konusunda daha ayrıntılı bir tartışma istiyorsanız, Güvenli Kod Yazma kitabından başlıyorum .


2
Durumun bu olup olmadığından emin değilim. Soru, veritabanının şifrelenmesi değil, veritabanındaki verilerin şifrelenmesi ile ilgilidir. Bu, sql sorgularındaki verilerin şifreleneceği anlamına gelir.
Manoj R

1
Performans isabeti küçük mü olmalı? Veriler üzerinde arama YAVAŞ olacaktır. Veriler şifrelendiğinde tüm indeksleme kavramı çalışmaz. Tam tablo taraması gerekir.
mike30

mike Yukarıdaki yaklaşım, hacmi şifreleyecek ve dizine ekleme vb. işlemlerini etkilemeyecektir.
jdigital

IMO, burada elde edebileceğinizden daha fazla uzmanlığa ihtiyacınız var. IANAL, ancak bence bu verilerden ödün verilirse müşterinizin oldukça yüksek bir maruziyeti var.
kevin cline

8

Bu tür güvenlik konularına karar vermeden önce tehdit modelini değerlendirmelisiniz. Neye karşı savunduğunuzu bilmeden, aldığınız önlemlerin değeri düşük olabilir.

Şimdi, bu bağlamda endişelenebileceğiniz birkaç şey var:

  • Verilerinize fiziksel erişim sağlayan saldırganlar (örn. Veri merkezine girme, yedekleme bantlarını çalma vb.)
  • Ham veritabanınıza okuma erişimi kazanan saldırganlar
  • SQL enjeksiyonu, arabellek taşmaları vb. Yoluyla uygulamanızın güvenliğini ihlal eden saldırganlar.

İlk senaryoda, sunucunun başsız olması şartıyla veritabanının ve tüm yedeklemelerin depolanması çalışmalıdır - sunucuyu veya bantları çalmak için disk düzeyinde şifrelemenin kırılması gerekir.

İkinci senaryoda, veritabanı verilerini şifrelemek yardımcı olur, ancak yalnızca gerekli anahtarları veya parolaları hiçbir yerde saklamıyorsanız.

Üçüncü senaryoda, her şey saldırının gerçekleştiği bağlama bağlıdır: örneğin bir XSS veya CSRF saldırısı ise, bir saldırgan meşru kullanıcının yapabileceği her şeyi yapabilir ve verilerinizi şifrelemek hiç yardımcı olmaz .

Bu nedenle tehdit modeliniz, oturum açma kimlik bilgilerini bularak ve veritabanı sunucusuna dışarıdan oturum açmayı yöneterek veya veritabanı sunucusuna kök erişimi kazanarak ham veritabanına okuma erişimi kazanan bir saldırgan. Tipik bir yol, önce web sunucusunda kabuk erişimi elde etmektir; oradan, bir saldırgan yapılandırma dosyasından erişim kimlik bilgilerini okuyabilir ve veritabanına bağlanabilir.

Ek bir husus, özellikle PHP gibi durum bilgisi olmayan bir yürütme modeline sahip bir platform kullanıyorsanız, anahtarları ve parolaları sakladığınız yerdir. İdeal olarak, müşterinin parolasını gerektiğinde yazması ve şifre çözme istemcisi tarafından yalnızca bellekte veya daha da iyisi tutması gerekir (ancak bu genellikle uygun değildir). Durum bilgisi olmayan bir platformda durum genellikle oturumlar, memcache, veritabanları veya düz dosyalar kullanılarak taşınır; ancak tüm bunlar durum bilgisi olan bir web uygulamasının kendi belleğinde kalmasından çok daha savunmasızdır. Bundan kaçınmak bir tavuk ve yumurta problemidir, çünkü devleti ısrar etmeden şifrelerseniz, güvenli bir şekilde hatırlamanız gereken başka bir sır oluşturdunuz. İstemcideki parolayı hatırlamak ve her istekle birlikte göndermek, o zaman en az korkunç çözüm olabilir;


2
+1: tehdit modeli olmadan, büyük olasılıkla ön kapıyı kilitlersiniz, ancak arka kapıyı tamamen açık bırakırsınız.
kevin cline

8

Bir an için müşterinin ne istediğini ve yasaların ne olduğunu göz ardı ederek ...

Hayır, muhtemelen verileri şifrelememelisiniz. Bunu yaparsanız, kolayca arayamazsınız. Örneğin, like 'Smith%'her ad girişi şifrelenmişse soyadı nasıl ararsınız? Eğer yapamazsanız hastanın kan basıncını zaman içinde nasıl grafiklendirirsiniz select .... from.... where patient_id = N?

Açıkçası, sunucunun düzgün bir şekilde güvenli olduğundan, ağ bağlantısının güvenli olduğundan ve kullanıcı arabiriminin düzgün bir şekilde güvenli olduğundan emin olun (kullanıcıların bilgisayarlarını kullanan herkese erişim izni bırakarak oturum zaman aşımları dahil). Veritabanı yedeklemelerini şifrelemek de isteyebilirsiniz. Ve fiziksel olarak sunucunun bulunduğu oda güvenli. Ama canlı verileri şifrelemek olmaz.

Açıklama: Bu OP aslında veriyi şifreleyerek olduğunu soruyordu Ne üstleniyor içinde veritabanı. Veritabanının bulunduğu dosya sistemi değil.


tamamen katılıyorum, ancak LAWS yapmıyor :(
Zalaboza

1
AES_DESCRYPT('') LIKE 'Smith%'İnanılmaz derecede yavaş da olabilirsiniz . Ya da yoğunlaşabilir ve tuzlanmış karmalarla ters bir indeks oluşturabilirsiniz
foochow

1

Eğer web uygulamasını CakePHP gibi etkili bir MVC çerçevesi kullanarak dikkatlice geliştirirseniz. Zend veya Rails ise, veri Modal düzeyinde şifrelemeyi etkinleştirebilmeniz / devre dışı bırakabilmeniz gerekir.

Örneğin CakePHP'nin verileri şifreleyen Modal'lar için birkaç Davranış örneği vardır. Süreci Kontrolörler ve Görünümlere şeffaf hale getirme.

Bunu yaparken dizin oluşturma ve diğer teknik veritabanı sorunları ile ilgili sorunları yoksayma. Bunu yapılandırılabilir bir seçenek olarak elde etmek mümkün olmalıdır.

Ayrıca, şifrelemeyi daha sonra ya da yalnızca üretim sunucusunda açacağım. Şifrelenmiş verilerin geliştirilmesi sırasında hata ayıklamak ve çalışmak zordur ve yalnızca belirli sütunlarda yapılabilir.


1

Evet, veritabanını şifrelemelisiniz.

Bu kişisel ve hassas bilgiler olduğu için kesinlikle olması gerektiğine inanıyorum.

Paroladan, yalnızca oturum için sakladığınız bir şifreleme anahtarı türetebilirsiniz. Bu şekilde, hiçbir yerde depolanmaz ve kimse (DBA'lar dahil) bunu bilemez, çünkü kimse de şifreyi bilmez. DB'yi doğrudan görüntülemeye çalışan herkes anlamsızca bakacaktır. Bunu bozmanın tek yolu oturum ele geçirme yoluyla olmakla birlikte, burada oturumların da güvenli olduğunu varsayıyorum.


İnsanlar parolalarını çok sık unutuyorlar ... o zaman ne?
curiousguy

-1

Kendime soruyorum neden müşteri DB'yi şifrelemenizi istiyor? Sizden verileri korumanızı isteyecek olsaydı, kabul ediyorum, ama zaten aklında örtük bir uygulama var. Ne hakkında konuştuğunu tam olarak bilmediği sürece, sadece bakış açımdan buzzwords atıyor.

Ben de DB şifrelemek çok işe yaramaz buluyorum, çünkü kelimenin tam anlamıyla her büyük DBMS güvenliği uygun ve muhtemelen olabildiğince daha iyi dikkate alır inanıyorum . DB'yi DBMS üzerinden erişmek için kimlik bilgilerine ihtiyacınız olacaktır. Şifrelenmiş bir DB durumunda, bu kimlik bilgilerine de ihtiyacınız olacak ve verilerin şifresini çözmek için zaten sahip olduğunuz kimlik bilgilerine ihtiyacınız olacaktır.

Bu zihniyetin ardından DBMS'nin güvenliği ele almasını ve kimlik bilgilerini kullanıcı girdisinden db erişimine kadar korumaya çalışmayı öneriyorum, aynı zamanda güçlü parolalar ve periyodik değişiklikler uygulayabilir.


... her büyük DBMS ... hesaba securityinto alır onlar değil hariç .
Jay Elston

Sormam gereken ilk soru, bunu nasıl yaptılar ve db'yi şifreleyerek hasarın nasıl önlenebileceğidir. Bu makaleyi hızlıca taradım, ancak kimlik bilgilerine sahip oldukları izlenimini edindim.
sschrass

Kesinlikle - DB Kimlik Bilgileri tehlikeye girebilir ve alabilir. Zorluk, sistemi, yetkisiz kullanıcılar kimlik bilgilerine erişebilse bile, hassas verilere erişebilmek için ek şifreleme anahtarlarına ihtiyaç duyacakları şekilde tasarlamaktır. Sağlık bilgisi için bu daha da karmaşıktır. DB kimlik bilgilerine erişimi olan herkes hassas verilere erişemez. Örneğin, DBA hasta verilerini düz metin olarak okuyamaz. Bu verileri okuyabilmesi gereken tek kişi hastalar ve sağlayıcılarıdır.
Jay Elston
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.