Veritabanındaki hassas veriler nasıl ayrılır (MySql)


9

Kullanıcıların kişisel hastalıkları hakkında bilgi içeren bir veritabanı tasarlamam gerekiyor.

DB tablolarının sütunlarını uygulamak için yaklaşım ne olabilir: bilgileri şifrelemek, iki farklı DB içinde verileri ayırmak, biri hassas veriler için diğeri hassas olmayan veriler için ya da her ikisi veya başka bir yaklaşım?


1
Verileri kimden korumak gerekiyor?
Oded

Güzel bir soru ama belki de dba.stackexchange.com/questions adresine taşınmalı mı?
FrustratedWithFormsDesigner

@Old dba veritabanı kullanıcısının hastalığı hakkında bilgi görüntülemek mümkün olmamalıdır.
carlo

2
Ama kim yapmamalı ?
Oded

1
Uygulama tarafında şifreleyebilirsiniz, ancak uygulamanın anahtarı olacaktır. Bu, verileri "giren" bir web uygulaması mıdır?
Ominus

Yanıtlar:


5

Verileri web uygulamanızda saklanan bir anahtarla şifreleyebilirsiniz, böylece veriler db'den şifrelenmiş biçimde yazılır / okunur. Ancak, koda erişimi olan herkes anahtarla ve anahtarla şifrelenmemiş verilere erişebilir. Bu gereksinimi çözer

dba veri tabanı kullanıcısının hastalığı hakkındaki bilgileri görüntüleyememelidir.

Veritabanlarını ayırmak için kullandığım sürece bunun gerekli olduğunu düşünmüyorum. Verileri şifrelenmiş olarak saklıyorsunuz ve kullanıcı tarafından veritabanı izinlerini kullanıyorsunuz, tablo (gerekirse bile) fazlasıyla yeterli olacak. Ekstra DB başka bir şey olmadan karmaşıklık katmanı ekler düşünüyorum. Farklı bir konumda olmadığı sürece, tek bir veritabanı sisteminden KÜÇÜK bir gelişme olabilir.


1
Ayrı veri tabanlarının diğer bir nedeni, hassas verilerin bir yargı sisteminde (bulutta değil) saklanması için yasal veya sözleşmeye bağlı bir gerekliliktir.
Gilbert Le Blanc

2

Ominus'un cevabı ilk sorunuza cevap verir. İkinci sorunun cevabı, başvurunuz hakkında daha fazla ayrıntı gerektirebilir.

Hastaların veritabanına erişmesi gerekiyorsa daha da fazla güvenlik sağlayan başka bir yaklaşım, her kullanıcı için ayrı bir veritabanına sahip olmak olabilir. Bu yaklaşımda, çok kiracılı, çoklu veritabanı işlevselliği sağlayan bir çerçeve kullanabilirsiniz. Ancak sorun, ayrı uygulama kullanıcılarınız ve ayrı veritabanı kullanıcılarınız varsa, bu kullanıcıları senkronize etmenin inanılmaz derecede zor olacağıdır. Hastaların veritabanınıza erişmelerine gerek olmadığını tahmin ediyorum. Gerekirse, kullanıcı başına bir anahtara sahip olmak en güvenli olabilir.

Yasal veya sözleşmeye bağlı gerekliliklere ek olarak, ayrı veritabanlarına sahip olmayı düşünebileceğim diğer bazı nedenler: müşterinin artan güvenlik algısı, satışları kolaylaştırmak, şifrelemenin kırılmasından endişe etmek ve anahtarların tehlikeye girmesinden endişe etmek.

Briddmus'un "sadece tıbbi bilgilerden daha fazlasını şifrelemeniz gerektiğini" belirttiği kısmıyla ilgili olarak: bu sadece veritabanındaki herkesin tıbbi bir durumu varsa geçerlidir. (Sanırım durum böyle).

Not: Bu cevabın bazı kısımları yorum olarak daha uygun olacaktır, ancak henüz yorum göndermek için yeterli temsilcim yok.


1

Bu tür bir uygulama için, verilere kimlerin erişmesine izin verilmesi gerektiğini düşünmeniz gerekir. Tıbbi bilgilerle, bunu giren kullanıcı ve görüntüleme izni verdikleri herkesle sınırlı olacağını düşünüyorum.

DBA'nın verileri görüntülemesini önlemek için, DBA'nın erişimi olmayan bir kod kullanarak şifrelemeniz gerekir.

Ayrıca bilgileri uygulama programcısının da erişemeyeceği şekilde şifrelemeniz gerekir. Bir programcı herhangi bir kullanıcı olarak oturum açabilirse, DBA'dan gelen bilgileri şifrelemenin bir anlamı yoktur.

Ayrıca tüm verileri aynı kodla şifrelemek de istemezsiniz. Yazılım, bir kullanıcıya diğerinin bilgilerini gösteren bir hata içerebilir. Bu nedenle, her kullanıcıya ait verileri o kullanıcıya özgü bir kod kullanarak şifrelemek en iyisi olacaktır.

Sadece tıbbi bilgilerden daha fazlasını şifrelemeniz gerektiğini not etmek önemlidir; son kullanıcı olarak DBA'nızın tıbbi bir rahatsızlığım olduğunu bilmesini bile istemezdim. Bu nedenle, kullanıcı hakkındaki kişisel olarak tanımlayıcı bilgileri de şifrelemeniz gerekir. Bu, aşağıdakileri içerir:

  • isim
  • doğum tarihi
  • e
  • seks
  • adres
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.